Distributed Computer Architecture and Process for Document Management

ABSTRACT

A system and/or method enables a typical PC user to add electronic paper processing to their existing business process. The system and/or method extends the notion of copying from a process that involves paper going through a conventional copier device, to a process that involves paper being scanned from a device at one location and copied to a device at another location. In its more sophisticated form, the system and/or method can copy paper from a device at one location directly into a business application residing on a network or on the Internet, or visa versa. The system and/or method is software that manages paper so that it can be electronically and seamlessly copied in and out of devices and business applications (such as Microsoft Office, Microsoft Exchange, Lotus Notes) with an optional single-step operation. The system and/or method can reside on a PC, LAN/WAN server, digital device (such as a digital copier), or on a web server to be accessed over the Internet.

RELATED APPLICATIONS

This application claims priority to and is a continuation of U.S. patentapplication Ser. No. 13/182,857 filed Jul. 14, 2011; which claimspriority to and is a continuation of U.S. patent application Ser. No.12/328,104, filed Dec. 4, 2008, now U.S. Pat. No. 7,986,426; whichclaims priority to and is a continuation of U.S. patent application Ser.No. 10/874,172 filed on Jun. 24, 2004, now U.S. Pat. No. 7,477,410 whichclaims priority and is a continuation of U.S. patent application Ser.No. 09/438,300, filed Nov. 12, 1999, now U.S. Pat. No. 6,771,381 whichclaims priority to U.S. Provisional Application 60/108,798, filed Nov.13, 1998, all of which are incorporated herein by reference.

This application is related to, a continuation-in-part application of,and claims priority to, the following non-provisional applications:

-   Ser. No. 08/950,838, filed Oct. 15, 1997, now U.S. Pat. No.    6,185,590;-   Ser. No. 08/911,083, filed Aug. 14, 1997, now abandoned;-   Ser. No. 08/950,911, filed Oct. 15, 1997, now abandoned;-   Ser. No. 08/950,837, filed Oct. 15, 1997, now abandoned;-   Ser. No. 08/950,738, filed Oct. 15, 1997, now abandoned;-   Ser. No. 08/950,741, filed Oct. 15, 1997, now abandoned;    all of which are hereby incorporated by reference.

This application is related to, and claims priority to, the followingprovisional applications by way the claim of priority of the abovelisted non-provisional applications:

-   Oct. 18, 1996, Ser. No. 60/028,129;-   Oct. 18, 1996, Ser. No. 60/028,522;-   Oct. 18, 1996, Ser. No. 60/028,128;-   Oct. 18, 1996, Ser. No. 60/028,697;-   Oct. 18, 1996, Ser. No. 60/028,639;-   Oct. 18, 1996, Ser. No. 60/028,685;    all of which are hereby incorporated by reference.

FIELD OF THE INVENTION

The present invention is generally related to a computer architectureand process for stand-alone and/or distributed environment, and moreparticularly to a computer architecture and process using asubstantially uniform management in a stand-alone and/or distributedcomputing environment including, for example, client server and/orintranet and/or internet operating environments.

BACKGROUND OF THE RELATED ART

A “C” or “C++”—Level API (hereinafter “C” Level), which is the nativelanguage and interface for a vast repository of core technologies fromsmall software vendors and research laboratories, are unique to eachdesigner. The designer of a text retrieval “C”-API will generallyimplement an interface that is completely different than a secondinventor creating a “C”-level API for OCR.

Every “C”-level API is unique, both in its choice of API syntax as wellas its method for implementing the syntax. Some API's consist of one ortwo functions that take parameters offering options for differentfeatures offered by the technology. Other APIs consist of hundreds offunctions with few arguments, where each function is associated with aparticular feature of the core technology. Other APIs provide a mixtureof some features being combined with one function with many arguments,while other features are separated into individual function calls.

Without any constraints, each designer of a core technology chooses toimplement his or her technology with an interface that is suitable tothe subject or simply was the most expedient choice of the moment. Sincethere are no constraints, a “C”-level API has a totally unpredictableinterface that can often be the hindrance to using the core technology.

Additionally, every API manages errors differently further complicatingthe problems described above. Some APIs return a consistent error codefor each function. Error management in this case is very organized andmanageable. Other APIs return error codes as one of the parameterspassed to the function. There are APIs that mix the choice of errormanagement and have some functions return an error code while otherfunctions pass the error code as a parameter of a function. Errors canalso be managed by a callback function, eliminating the need for passingany error code as part of the function. In some instances of a poorlyimplemented API the errors are not passed back at all.

Every engine, such as a text retrieval or an OCR (Optical CharacterRecognition) engine, has a unique interface. This interface is generallya “C”-level API (Application Program Interface). Further, an API can atany time be synchronous, asynchronous, manage one or more callbacks,require input, pass back output, carry a variety of different styles offunctions, return values or not return values, and implement theunpredictable. This unpredictability in APIs further compounds theproblem of developing a sane way of interfacing between components andAPIs.

To date, because of the complexities of “C”-level APIs and componentsinterfacing thereto, the only way to create a component out of anexisting “C”-level API is to have an experienced programmer in the fieldto do the work. Humans can intelligently analyze an API, and create acomponent based on intelligent decisions and experiences. In most cases,the learning curve for understanding and integrating a new engine can beone man-month to several man-years and generally requires highlyexperienced “C” programmers. Requiring a human to perform the necessarywork is costly, and subject to real-life human constraints.

Since there is no structure or format for implementing “C”-level APIs,the ability to automatically transform a unique API into a standardcomponent would seem impossible, since that would take a nearly-humanlevel of intelligence.

In addition, in spite of the continued automation of business processes,companies are increasing their paper use by 25-30% and spending up to15% of their total budget on managing paper. Companies are often runningdual processes—a computerized process along with the corresponding paperfiling system—and paying an extraordinary price for it. Just a fewexamples will illustrate the problem: 1) accounting clerks aremaintaining paper invoices with information that is also being re-keyedinto accounting systems, 2) administrative assistants are filingincoming correspondence in cabinets for customers whose records are alsobeing electronically maintained by contact management systems, 3) helpdesk operators are storing complaints sent in on paper while alsotracking those complaints in a computerized system. Additional industrytrends include the following:

-   -   For every $100M in increased revenues, a company will use 8.8        million additional pages of paper    -   The Document Management market is expected to grow at 30% per        year    -   The digital device market is growing at 20% per year    -   Estimates show the web-based document imaging market growing at        50% per year    -   The digital device manufacturers, especially the copier        companies, are heavily promoting the ability to connect their        devices to networks, but have not been able to deliver an        effective software solution to date.

Businesses continue to automate more processes, but managing theassociated paper is often ignored, resulting in inefficiency and highercosts.

I have determined that a component factory, if it is to be trulyautomated or manually expedited, must be able to take any “C”-level APIand transform it into a component.

I have also determined an efficient and workable design for anarchitecture to define the migration path for any “C”-level API into acomponent.

I have also determined that it is desirable to develop software toolsfor automatically generating reusable software components from coresoftware technologies, thus making these software technologies availableto a much larger user base.

I have further determined that it is desirable to design a distributedcomputer architecture and process for manually and/or automaticallygenerating reusable software components. The computer architecture maybe implemented using a client server and/or intranet and/or internetoperating environments.

I have further determined that it is desirable to design a computerarchitecture and process for image viewing in a stand-alone and/ordistributed environment. The computer architecture and processoptionally uses a substantially uniform management layer in astand-alone and/or distributed computing environment including, forexample, client server and/or intranet and/or internet operatingenvironments.

I have further determined that it is desirable to enable a typical PCuser to add electronic paper processing to their existing businessprocess.

I have further determined that it is desirable to enable software thatmanages paper so that it can be electronically and seamlessly copied inand out of devices and business applications (such as Microsoft Office,Microsoft Exchange, Lotus Notes) with an optional single-step Gooperation.

SUMMARY OF THE INVENTION

One would expect the translating a “C”-level API from its native stateinto a component would require human-level intelligence. This is mainlybecause “C”-level APIs have virtually no constraints as to how they canbe implemented. This means that there are an infinity variations ofAPIs, which can only be managed by human-level intelligence. While thispoint is true, I have determined that the appropriate solution starts atthe other side of the equation, which is the component itself.

My solution starts out with a definition of a component that can sustainthe feature/function requirements of any API. In other words, theinterface of a generic component can be defined such that the featuresand functions of virtually any API can be re-implemented within itsbounds. The two known end-points are, for example, the “C”-level APIthat generally starts with each component (although other programminglanguages may also be used and are within the scope of the presentinvention), and the component interface that represents any set offeatures/functions on the other side. The component factory migrates theoriginal “C”-level API from its original state into the genericinterface defined by the topmost layer. The first feature that can bedemonstrated is that there is a topmost layer that can define acomponent interface that can represent the features/functions of mostcore technologies.

The component factory migrates the “C”-level API to the topmost level.Doing this in one large step would be impossible since the “C”-level APIhas a near-infinite variety of styles. However, the architectureadvantageously has enough well-defined and well-structured layers forimplementing the topmost component interface, for creating the componentfactory.

The computer architecture is designed for managing a diverse set ofindependent core technologies (“engines”) using a single consistentframework. The architecture balances two seemingly opposingrequirements: the need to provide a single consistent interface to manydifferent engines with the ability to access the unique features of eachengine.

The benefit of the architecture is that it enables a company to rapidly“wrap” a sophisticated technology so that other high-level developerscan easily learn and implement the core technology. The computerarchitecture is therefore a middleware or enabling technology.

Another benefit of the architecture is that it provides a high-levelspecification for a consistent interface to any core technology. Once ahigh-level developer learns the interface described herein for oneengine, that knowledge is easily transferable to other engines that areimplemented using the architecture. For example, once a high-leveldeveloper learns to use the computer architecture for OCR (OpticalCharacter Recognition), using the computer architecture for otherengines, such as barcode recognition or forms processing, is trivial.

The architecture described herein is, at once, a framework for rapidlywrapping sophisticated technologies into high-level components, as wellas a framework for high-level developers to communicate with a diverseset of engines. The creating of a component factory is based on the factthat the architecture defines a clear path for “wrapping” any C-levelAPI into a component using simple structures and many rote steps. Thisprocess is currently being done in an inefficient manner by a programmerin the field.

In addition, the method described herein for creating a componentfactory creates a well-defined multi-tiered architecture for a componentand automates, substantially automates, or manually expediteshereinafter automate the process of migrating a “C”-API from its nativestate through the various tiers of the architecture resulting in astandardized component. Advantageously, the method described herein doesnot base the component factory on making human-level intelligentdecisions on how to translate a “C”-API into a component. Rather, bycreating a well-defined architecture described below that ismulti-tiered, the method is a series of incremental steps that need tobe taken to migrate the “C”-API from one tier within the architecture tothe next. In this way each incremental step is not a major one, but insequence the entire series of steps will result in a component.

Since each step of migration is not a major one, the chances forautomating these steps is significantly higher and the likelihood ofbeing able to create the component factory becomes feasible. Thisapproach is in fact what makes the method cost-effective, since thealternative approach, i.e., computer-generated human-level decisionmaking, has many years before becoming sophisticated enough to replacehumans in any realistic decision-making process.

The main features of the architecture are twofold:

-   1) Defining system architecture that describes in detail how to    implement a component from a “C”-level API;-   2) Creating a component factory by automating the migration of a    “C”-level API from one tier within the architecture to the next.    The latter feature is the key to actually making the component    factory feasible. With a fixed architecture that can be used to    implement a “C”-level API as a component (using a programmer), that    same architecture can be used as the basis for the component factory    model.

In order to make the component factory, each step of the architectureneeds to be designed to facilitate automation or manually expedited. Inother words, I have determined that automating/expediting the process oftaking the original “C”-level API and migrating it to a Level 1 layer,and then a Level 1 to a Level 2, and then a Level 2 to a Level 3 layer,and so on, the component has been implemented automatically or moreefficiently. The component factory is therefore a sum of the ability toautomate migrating the “C”-level API from one layer to the next within awell-defined architecture for implementing components.

There are numerous core technologies, such as text-retrieval and ICR(Intelligent Character Recognition), that have already been implemented,and are only available as “C”-level APIs. Many, if not most, coretechnologies are first released exclusively as “C”-level APIs. Whilethere are integrators and corporations who have the team oftechnologists who can integrate these “C”-level APIs in-house, mostcompanies are looking for component versions that can be implemented ata much higher level.

Therefore, many of the core technologies that are only available in a“C”-level API are not being used due to their inaccessible interface.The benefit of the component factory is that it can rapidly makeavailable core technologies implemented as “C” APIs that would otherwisebe underutilized or dormant in research labs by converting them tohigh-level components that can be used by millions of power-PC users.

With the advent of the World Wide Web (WEB) this opportunity hasincreased exponentially. The WEB is now home to a vast number of WEBauthors with minimal formal training who can implement HTML pages andbuild web sites. One of the fundamental technologies for extending thecapability of the WEB from simple page viewing to interactive andsophisticated applications is components.

A component extends the capability of HTML by enabling a WEB author toadd core technology as a pre-packaged technology. Since components arefundamental to the growth and usability of the WEB, having a componentfactory that can translate “C”-level toolkits into components that arethen usable within WEB sites opens a vast and new worldwide market tothese technologies.

The purpose of the Virtual Copier (“VC”) aspect of the present inventionis to enable a typical PC user to add electronic paper processing totheir existing business process. VC is an extension of the concept weunderstand as copying. In its simplest form it extends the notion ofcopying from a process that involves paper going through a conventionalcopier device, to a process that involves paper being scanned from adevice at one location and copied to a device at another location. Inits more sophisticated form, VC can copy paper from a device at onelocation directly into a business application residing on a network oron the Internet, or visa versa. The VC invention is software thatmanages paper so that it can be electronically and seamlessly copied inand out of devices and business applications (such as Microsoft Office,Microsoft Exchange, Lotus Notes) with an optional single-step Gooperation. The VC software can reside on a PC, LAN/WAN server, digitaldevice (such as a digital copier), or on a web server to be accessedover the Internet.

Virtual Copier is designed to solve the corporate paper problem byenabling existing web-based and client-server applications to managepaper as part of their solution. Virtual Copier links the familiar anduniversal world of paper and digital devices to web-based andclient-server applications. The result is that the automated businessprocesses become the primary storage of paper in electronic form.Information that is typically managed and processed in paper form is“copied” into the system and managed by the business processes withwhich users are accustomed, which is made possible by using VirtualCopier. Simple extensions of Virtual Copier support seamless electronicoutsourcing of paper processing and archival services over the web.

Virtual Copier is a unique combination of an intuitive application builton an open component architecture that delivers a simple innovation:provide paper processing to existing Intranet and client-server businessprocesses without any fuss. Whether it is an office clerk that needs toeasily copy a report from a desktop scanner to the company'sIntranet-networked copier, or an accounting software integrator thatwants to embed paper processing, Virtual Copier offers a simplesolution. To the office clerk Virtual Copier is a document imagingapplication packaged in the familiar setting of an office copier. To theintegrator, the underlying open architecture of Virtual Copier offers asimple integration path for embedding paper processing into itsclient-server or web-based software solution.

Although managing paper manually is one of the great problems facingcorporations, there has been little innovation in enabling those workersto eliminate the need to continuously work with paper manually. Much ofthe problem stems from the complexity of traditional document managementsystems, which require days of training and months to become familiarwith the system in order to be proficient. Virtual Copier was designedto be as simple as a copier to operate, and yet still provide thecomplete capability of integrating paper with existing businessapplications. By simplifying the interface and underlying softwareinfrastructure, VC can manage paper in electronic form as easily as iscurrently done in physical form.

VC extends the notion of a copier, which simply replicates the image ofan original document onto another piece of paper using a single GO orSTART button, to do a similar operation in software so that the imagegets seamlessly replicated into other devices or applications or theInternet.

An example of this is the actual implementation of Virtual Copier as aconsumer product. The interface of the consumer product called VirtualCopier has a Go button much like a physical copier. This GO button cancopy paper, whether physical or electronic, from one device and orapplication to another device and/or application.

What makes Virtual Copier as simple as its physical counterpart in atleast one embodiment is the fact that it replicates the identicalmotions that a user who is making a copy using a physical photocopiergoes through. When a user photocopies a document, he/she selects wherethey want to copy from (i.e. the sheet feeder), where the user wants tocopy to (i.e. 6 copies collated and stapled) and then presses a GObutton to actually carry out the photocopy process. With Virtual Copierthe process feels familiar because the sequence is the same with justthe Power VC portion of the main Virtual Copier window.

The power of Virtual Copier is the fact that the From can be a physicaldevice (e.g. digital copier, fax or scanner) or an application (e.g.Lotus Notes, Microsoft Exchange, the Internet, or an electronic filingsystem). The To can also be a physical device (e.g. a fax, digitalcopier, or printer) or an application (e.g. Lotus Notes, MicrosoftExchange, the Internet, or an electronic filing system). Even thoughpaper is being copied electronically from devices to applications, fromapplications to devices, from devices to devices, or from applicationsto applications, the user simply has one sequence to execute: selectFrom, select To, and then press GO. Virtual Copier will accomplish alltranslations between device and applications automatically andseamlessly.

Another reason that paper is still a major corporate issue is thattraditional document management systems require that a company invest ina whole new system just to store electronic images. Although this is theonly way that document management systems have been designed anddelivered, it is in fact highly inefficient. Most companies alreadymanage information about physical documents in some form of softwareapplications.

For example, accounting systems have long been used to maintaininformation about invoices and bills that arrive into a company fromoutside sources as physical pieces of paper. When an invoice arrives,its information is keyed into the accounting software, where balancesare maintained and accounts payable information is coordinated. Yet theoriginal invoice is stored manually, and every time that a request ismade for a copy of the signed invoice, someone manually retrieves theinvoice from a physical filing cabinet. Accounting systems, like mostbusiness applications, typically have no way of maintaining anelectronic copy of the physical invoice, and adding a documentmanagement system to an accounting system is cumbersome, costly, anddifficult to maintain, and even more difficult to coordinate.

Virtual Copier solves this problem in at least one embodiment by copyingpaper directly into the existing accounting system. Simply adding a Toitem in the Virtual Copier window enables a user to copy paper directlyinto the appropriate accounting record of the existing accountingsystem. This requires no retraining (users who are trained on theaccounting system will still use the accounting system in the same way),requires no document management system (the electronic copy of thedocument is actually being maintained by the accounting system itself),there is no coordination between two systems (Virtual Copier embeds theinvoice with the appropriate accounting record), and it is simple (oneGo button).

What is true with regard to the example above of an accounting system istrue of most other business applications. The power of Virtual Copier isthat it can turn an information system into a document management systemby adding support for electronic paper directly into the existingbusiness application, whether it is a client, server-based, or web-basedsystem.

Virtual Copier enables corporations to perform sophisticated documentimaging with their existing Web-based and client-server applicationsthrough a user interface that is as familiar as the office copier.Virtual Copier can be used out-of-the-box as a standalone application tocopy, scan, fax, or print images using existing digital devices withincorporate environments or across the web. With the extensions, asdescribed below, Virtual Copier can be integrated into Web-based andclient server applications, such as ERP or accounting systems, toeliminate paper from existing business processes and legacyapplications. Virtual Copier can also be used to support seamless accessto document image processing and archival over the web since, in atleast one embodiment, the VC interface is implemented as a softwareapplication.

VC is architected as an application that delivers end-user functionalitywhile remaining open to third-parties extensions. For example, VC can beviewed as a copier. Like a copier, VC takes paper in, and produces papergoing out. The only difference is that VC does not distinguish betweenelectronic and physical paper.

To accommodate third-party extensions, VC is divided into five essentialmodules. Each module is a counterpart to an aspect that is found on aconventional copier. Based on the modular design of VC, each aspect ofVC can be independently extended, offering much greater flexibility thanconventional copiers.

The five core modules of VC are:

Input Module—The Input Module manages paper or electronic paper enteringVC. This module manages imaging devices to input paper through scanners,MFPs, or the new breed of digital copiers. The Input Module also managesreading electronic paper from third-party or proprietary applications.The counterpart to VC's Input Module on a conventional copier is thescanner subsystem.

Output Module—The Output Module manages paper or electronic paperexiting VC. Like the Input Module, this module manages imaging devicesto output paper to standard Windows printers, specialty image printers,MFPs, or the new breed of digital copiers. The Output Module alsomanages writing electronic paper to third-party or proprietaryapplications. The counterpart to VC's Output Module on a conventionalcopier is the printer or fax subsystem.

Process Module—The Process Module applies processing to the electronicpaper as it is being copied. Examples of a process are OCR and ICR. TheProcess Module can also apply non-imaging functionality as well, such asworkflow or other relevant tie-ins to the electronic paper as it isbeing copied. One of the advantages of VC over conventional copiers isthat multiple processes can be applied to a single virtual copy. Thecounterpart to VC's Process Module on a conventional copier is thecontroller.

Client Module—The Client Module presents the electronic paper as it isbeing copied, and any relevant information related to the input oroutput functions. For example, if the Output Module is directed to aprinter, then the Client Module might present the finishingcapabilities; if the Output Module is directed to Goldmine, then theClient Module might present the target contact record to which thedocument is being copied. The counterpart to VC's Client Module on aconventional copier is the panel.

Server Module—Unlike conventional copiers, VC's Server Module is aunique subsystem that can communicate with the other modules as well asthird-party applications. The Server Module is what makes VC a far morepowerful concept than simply an application that can control a scannerand a printer to mimic a copier. The Server Module can be used tocombine third-party applications with the new breed of digital imagingdevices to create unique and custom virtual copier solutions. A virtualcopier can be created with VC by combining a scanner with a printer; orby combining a scanner with an application; or by combing an applicationwith an image printer. In each case VC is dynamically creating a customvirtual copier, with a complete understanding of how paper flows fromthe source to its destination. There is no counterpart to VC's ServerModule on a conventional copier.

One of the primary design goals of VC is to make it simple to integrateVC with third-party applications. There are two options to integratingVC into a third-party application: running VC as an external service, orembedding VC as an underlying service.

VC is in one embodiment and optionally a standalone application thatenables a user to scan (copy) paper from a device to a third-partyapplication, and to print (copy) the reference of an image document froma third-party application to a printing device. VC does not require thethird-party application to be aware that VC is operating. Rather, VCrecognizes that the third-party application is running, and itintelligently copies paper to and from that application.

In this scenario the user is interacting with VC's Client Module inorder to execute a copy operation to and from the third-partyapplication. There does not have to be any changes made to thethird-party application, not even to its interface, in order for VC tooperate. The user of VC only knows that to copy to and from thethird-party application, a custom Input and Output Module must beselected, and the Go button is pressed.

In order to support copying to and from a third-party application, VCmust be able to support extensions that understand each third-partyapplication. This is accomplished through the Input and Output Modules.The Client, Server, and even Process Modules remain independent acrossthird-party applications. However, in order to support outputting to athird-party application, an Output Module is developed that is unique tothat third-party application. Likewise, an Input Module is developedthat is unique to a third-party application in order to support readingimages from that application.

It is the optional Input and Output Modules that render VC extendable.For each third-party application there is a unique pair of Input andOutput Modules that understand the third-party application, and how tocopy images to and from that application. Each Input and Output Moduleregisters itself to the Windows registry so that the Server Module knowshow to find them. In this way Virtual Copier can grow indefinitely, tosupport any number of third-party applications.

The significant point is that the Input and Output Modules have theirown interface, and can be developed independently from any other module.As long as the Input and Output Module conform to the API specified inthis document it will plug-and-play with VC. VC will be able to mix andmatch the custom Input and Output Module with its standard and othercustom Input and Output Modules.

A third-party application can also use the services of VC without itsuser interface. That is, a third-party application can embed VC'sfunctionality and provide its own interface to its functionality. Forexample, rather than have VC as a separate application, a special buttoncan be placed on a third-party application that launches VC in thebackground.

VC is designed so that the Server Module can run independently from theClient Module. All the core functionality, including communicating withthe Input, Output, and Process Modules, are performed directly by theServer Module. The Client Module is generally simply an interface to theServer Module. Therefore, all the services of the Server Module can bemade available in the background to a third-party application withoutthe need for an interface. The third-party application can in factbecome the user's interface to VC.

In order to support VC operating in the background a third-partyapplication merely has to communicate with the Server Module directly,as described later in this document. The Server Module, as all modulesin VC, support COM-based interfaces for simple and direct support fromall major Windows development environments.

Accordingly, it is a feature and advantage of the present invention toimplement a component factory, that is automated or manually expedited.

It is another feature and advantage of the present invention to be ableto take any “C”-level API and transform it into a component.

It is another feature and advantage of the present invention to definean efficient and workable design for an architecture to provide themigration path for any C-level API into a component.

It is another feature and advantage of the present invention to developsoftware tools for automatically generating reusable software componentsfrom core software technologies.

It is another feature and advantage of the present invention to developsoftware tools to make software components available to a much largeruser base.

It is another feature and advantage of the present invention inproviding a distributed computer architecture and process for manuallyand/or automatically generating reusable software components.

It is another feature and advantage of the present invention inproviding a distributed computer architecture and process for manuallyand/or automatically generating reusable software components where thecomputer architecture is implemented using a client server and/orintranet and/or internet operating environments.

It is another feature and advantage of the present invention inproviding a computer architecture and process for image viewing in astand-alone and/or distributed environment.

It is another feature and advantage of the present invention inproviding a computer architecture and process that uses a substantiallyuniform management layer in a stand-alone and/or distributed computingenvironment including, for example, client server and/or intranet and/orinternet operating environments.

It is another feature and advantage of the present invention to enable atypical PC user to add electronic paper processing to their existingbusiness process.

It is another feature and advantage of the present invention to enablesoftware that manages paper so that it can be electronically andseamlessly copied in and out of devices and business applications (suchas Microsoft Office, Microsoft Exchange, Lotus Notes) with an optionalsingle-step Go operation.

The present invention is based, in part, on my discovery that it ispossible to make the component factory, and that each step of thearchitecture is designed to facilitate automation or manually design ofcomponents. The present invention is also based, in part, on mydiscovery that by automating/expediting the process of taking theoriginal “C”-level API and migrating it to a Level 1 layer, and then aLevel 1 to a Level 2, and then a Level 2 to a Level 3 layer, and so on,the component has been implemented automatically and/or more manuallyefficiently. The component factory is therefore a sum of the ability toautomate migrating the “C”-level API from one layer to the next within awell-defined architecture for implementing components.

The present invention is also based, in part, on my discovery that theobject manager and engine object component layers may be advantageouslybe designed to operate independently, thereby making possible adistributed computing environment, as described below in detail. I havefurther discovered that an efficient method of implementing the engineobject component layer is by using pre-populated tables/files. I havefurther discovered that the engine management layer may beadvantageously divided into a three layer structure of load/unloadengine, dynamic linking engine function calls, and initialize enginesetting.

In accordance with one embodiment of the invention, a computerimplemented process migrates a program specific Application ProgrammerInterface (API) from an original state into a generic interface bybuilding an object for each engine. The object provides substantiallyuniform access to the engine and engine settings associated with theengine. The computer implemented process includes the step of providingan engine management function interfacing with the program specific API.The engine management function furnishes a protective wrapper for eachfunction call associated with the engine, trapping errors, and provideserror management and administration to prevent conditions associatedwith improper engine functioning. The process optionally includes thestep of providing an engine configuration function transforming APIcalls received from the program specific API into standardized calls.The engine configuration function provides additional functionality,including safely loading and unloading the engine. The processoptionally includes the step of providing an engine function managingthe standardized calls for each engine, thereby providing substantiallyuniform access to the engine and the engine settings associated with theengine.

In accordance with another embodiment of the invention, a computerimplemented method migrates at least one program specific ApplicationProgrammer Interface (API) from an original state into a genericinterface by building an object for each engine. The object providessubstantially uniform access to the engine and engine settingsassociated with the engine. The computer implemented method includes thesteps of defining a substantially consistent interface for individualobject components that represent diverse technologies, and migrating aplurality of engines to the consistent interface. The computerimplemented method also includes the step of substantially automaticallyand/or substantially uniformly, managing the individual objectcomponents using a predefined object manager and the consistentinterface.

In accordance with another embodiment of the invention, a computerarchitecture migrates at least one program specific ApplicationProgrammer Interface (API) from an original state into a genericinterface by building an object for each engine. The object providessubstantially uniform access to the engine and engine settingsassociated with the engine. The computer architecture includes an enginemanagement layer interfacing with the program specific API and providingengine management and administration, an engine configuration layertransforming API calls received from the program specific API intostandardized calls, and an engine layer managing the standardized callsfor each engine.

In accordance with another embodiment of the invention, an enginemanagement layer configures a computer architecture to perform one ormore computer implemented or computer assisted operations. The computeroperations include one or more of loading and unloading engine dynamiclink libraries into and out of memory for each engine, mapping at leastone engine function to at least one corresponding engine object,providing general error detection and error correction for each engine,determining and matching arguments and returning values for mapping theat least one engine function to the at least one corresponding engineobject, and/or managing error feedback from the at least one programspecific API. In accordance with another embodiment of the invention, adistributed computer system migrates a program specific ApplicationProgrammer Interface (API) from an original state into a genericinterface by building an object for each engine. The object providessubstantially uniform access to the engine and engine settingsassociated with the engine. The distributed computer system includes aserver configured to include at least one engine having an engineinterface providing one or more features to be executed, and at leastone engine component configured to execute the one or more features ofthe engine by mapping a substantially consistent interface to the engineinterface of the engine. The distributed computer system also includesat least one client configured to be connectable to the server andoptionally configured to be connectable to another server. The clientincludes an object manager layer communicable with and managing the atleast one engine component stored on the server via the substantiallyconsistent interface.

In accordance with another embodiment of the invention, a distributedcomputer implemented process migrates a program specific ApplicationProgrammer Interface (API) from an original state into a genericinterface by building an object for each engine. The object providessubstantially uniform access to the engine and engine settingsassociated with the engine. The computer implemented process includesthe step of providing, on a server, at least one engine having an engineinterface, and providing one or more features to be executed. Thecomputer implemented process also includes the step of providing, on atleast one of the server and another server connectable to the server, atleast one engine component configured to execute the one or morefeatures of the engine by mapping a substantially consistent interfaceto the engine interface of the engine. The computer implemented processalso includes the step of providing, on a client configured to beconnectable to the server and optionally configured to be connectable tothe another server, an object manager layer communicable with andmanaging the at least one engine component via the substantiallyconsistent interface.

In accordance with another embodiment of the invention, an image viewerprocess views at least one document image including an electronicdocument image, and performs viewing operations to the electronicdocument image. The process includes the step of selecting, by the user,one of a plurality of image viewing perspectives. Each of the pluralityof image viewing perspectives provide the user the capability of viewingthe document image in accordance with a different predefined userperspective. The process also includes the steps of selecting, by theuser, using the image viewer process the document image to be viewed,and retrieving, by the image viewer process, the document image. Theprocess also includes the step of displaying, by the image viewerprocess, the selected document image in accordance with an image viewingperspective selected by the user.

In accordance with another embodiment of the invention, a computerreadable tangible medium is provided that stores the process thereon,for execution by the computer.

A computer data management system includes at least one of an electronicimage, graphics and document management system capable of transmittingat least one of an electronic image, electronic graphics and electronicdocument to a plurality of external destinations including one or moreof external devices and applications. The computer data managementsystem is responsively connectable at least one of locally and via theInternet, and includes at least one memory storing a plurality ofinterface protocols for interfacing and communicating, and at least oneprocessor responsively connectable to the at least one memory. Theprocessor implements the plurality of interface protocols as a softwareapplication for interfacing and communicating with the plurality ofexternal destinations including the one or more of the external devicesand applications.

In one embodiment, the external devices and applications include, forexample, a printer, a facsimile, and a scanner. In one embodiment, thecomputer data management system includes the capability to integrate animage using software so that the image gets seamlessly replicated andtransmitted to at least one of other devices and applications, and viathe Internet. In one embodiment, the computer data management systemincludes the capability to integrate the electronic images into adestination application without the need to modify the destinationapplication.

In one embodiment, the computer data management system includes aninterface that enables copying images between physical devices,applications, and the Internet using a single “GO” operation. In oneembodiment, the computer data management system includes the capabilityof adding at least one of electronic document and paper processing witha single programming step.

In one embodiment, the software application includes at least one inputmodule managing data comprising at least one of paper and electronicpaper input to the computer data management system, and managing atleast one imaging device to input the data through at least one of ascanner and a digital copier, and managing the electronic paper from atleast one third-party software applications; at least one output modulemanaging the data output from the computer data management system,managing at least one imaging device to output the data to at least oneof a standard Windows printer, an image printer, and a digital copier,and managing the output of the data to the third-party softwareapplication; at least one process module applying at least one dataprocessing to the data comprising the at least one of the paper and theelectronic paper as it is being copied, applying additionalfunctionality including at least one of workflow and processingfunctionality to the data comprising the at least one of paper andelectronic paper as it is being copied, and applying multiple processesto a single virtual copy; at least one client module presenting the datacomprising the at least one of paper and electronic paper as it is beingcopied, and information related to at least one of the input and outputfunctions; and at least one server module communicable with said atleast one input, output, client, and process modules and externalapplications, and capable of dynamically combining the externalapplications with at least one of digital capturing devices and digitalimaging devices.

In one embodiment, one or more of the external devices and applicationsintegrates the computer data management system into an externalapplication via one of running the computer data management system, asan external service and embedding the computer data management system asan embedded service.

In one embodiment, the server module includes enable virtual copyoperation means for initiating, canceling, and resetting said computerdata management system; maintain list of available module means formaintaining a registry containing a list of said input, output, andprocess modules that can be used in said computer data managementsystem, said list being read on startup, and maintaining another copy ofsaid list in a modules object accessible by said input, output, client,process and server modules; maintain currently active modules means formaintaining said input, output, and process modules currently being usedfor a current computer data management system copy operation in aprogram object, and saving the currently active modules in a processtemplate file; and maintain complete document information means formaintaining information regarding a current file being copied, andsaving the information in a document template file.

In one embodiment, the server module includes at least one server moduleapplication programmer interface (API). In one embodiment, the servermodule application programmer interface (API) comprises the COM-basedinterfaces: at least one modules object maintaining a first list ofavailable input, output, and process modules; at least one programobject maintaining a second list of currently selected input, output,and process modules; at least one document object maintaininginformation regarding a current document being copied; at least onesystem management method object used to initiate, cancel, and reset saidcomputer data management system; and at least one system managementevent object used to provide feedback to the Client Module.

In one embodiment, a computer data management system includes at leastone of an electronic image, graphics and document management systemcapable of transmitting at least one of an electronic image, electronicgraphics and electronic document to a plurality of external destinationsincluding one or more of external devices and applications responsivelyconnectable at least one of locally and via the Internet. The computerdata management system comprises: a first capability to integrate animage using software so that the image gets seamlessly replicated intoat least one of other devices and applications, and via the Internet; asecond capability to integrate electronic images into existingapplications without the need to modify the destination application; aninterface comprising a software application that enables copying imagesbetween physical devices, applications, and the Internet using a single“GO” operation; and a third capability of adding at least one ofelectronic document and paper processing with a single programming step.

A computer data management system capable of managing and transmittingat least one of an electronic image, electronic graphics and electronicdocument to a plurality of external destinations including one or moreof external devices and applications at least one of locally and via theInternet. The computer data management system includes at least onememory storing at least one of a common and universal interface protocolfor interfacing and communicating; and at least one processorresponsively connectable to said at least one memory, and implementingthe at least one common and universal interface protocol as a softwareapplication for interfacing and communicating with the plurality ofexternal destinations including the one or more of the external devicesand applications.

In one embodiment, a computer readable tangible medium storesinstructions for implementing a process driven by a computer implementedon at least one of an electronic image, graphics and document managementsystem capable of managing and transmitting at least one of anelectronic image, electronic graphics and electronic document to aplurality of external destinations including at least one of an externaldevice and application at least one of locally and via the Internet. Theinstructions control the computer to perform the process of: storing atleast one of a common and universal interface protocol for interfacingand communicating in at least one memory; and implementing the at leastone of common and universal interface protocol as a software applicationvia at least one processor for interfacing and communicating with theplurality of external destinations including the at least one externaldevice and application.

In one embodiment, a computer data management system includes at leastone of an electronic image, graphics and document management systemcapable of transmitting at least one of an electronic image, electronicgraphics and electronic document to a plurality of external destinationsincluding one or more of external devices and applications responsivelyconnectable at least one of locally and via the Internet. The computerdata management system includes a single function copy operation linkingdevices, applications and the Internet including at least one a gooperation, a single function paper copy between devices and softwareapplications, and a single function paper copy between softwareapplications and devices; a one step programming method to add papersupport to electronic business processes including at least one of a onestep method of supporting paper within electronic business processapplication optionally including legacy systems with no or minimalreprogramming of the electronic business process application, a methodof recreating a module oriented copier in software; and a copierinterface implemented as software application including at least one ofa virtual copier interface method of presenting to a user an operationof at least one of copying files and electronic images, at least one ofto and from, at least one of digital imaging devices and softwareapplications, in a substantially single step, and presenting users withdirect access to at least one of tutorial and options from a mainapplication window.

In one embodiment, a server module includes enable virtual copyoperation means for initiating, canceling, and resetting said computerdata management system; maintain list of available module means formaintaining a registry containing a list of said input, output, andprocess modules that can be used in said computer data managementsystem, said list being read on startup, and maintaining another copy ofsaid list in a modules object accessible by said input, output, client,process and server modules; maintain currently active modules means formaintaining said input, output, and process modules currently being usedfor a current computer data management system copy operation in aprogram object, and saving the currently active modules in a processtemplate file; and maintain complete document information means formaintaining information regarding a current file being copied, andsaving the information in a document template file.

In one embodiment, a computer data management method includes at leastone of an electronic image, graphics and document management systemcapable of transmitting at least one of an electronic image, electronicgraphics and electronic document to a plurality of external destinationsincluding one or more of external devices and applications responsivelyconnectable at least one of locally and via the Internet. The methodcomprises the steps of integrating an image using software so that theimage gets seamlessly replicated into at least one of other devices andapplications, and via the Internet; integrating electronic images intoexisting applications without the need to modify the destinationapplication; interfacing via a software application enabling copyingimages between physical devices, applications, and the Internet using asingle “GO” operation; and adding at least one of electronic documentand paper processing with a single programming step.

In one embodiment, a server method includes initiating, canceling, andresetting said computer data management system; maintaining a registrycontaining a list of said input, output, and process modules that can beused in said computer data management system, said list being read onstartup, and maintaining another copy of said list in a modules objectaccessible by said input, output, client, process and server modules;maintaining said input, output, and process modules currently being usedfor a current computer data management system copy operation in aprogram object, and saving the currently active modules in a processtemplate file; and maintaining information regarding a current filebeing copied, and saving the information in a document template file.

A computer data administration system includes at least one of anelectronic image, graphics and document administration system capable oftransmitting at least one of an electronic image, electronic graphicsand electronic document to a plurality of external destinationsincluding one or more of external devices and applications. The computerdata administration system is responsively connectable at least one oflocally and via the Internet, and includes at least one memory storing aplurality of interface protocols for interfacing and communicating, andat least one processor responsively connectable to the at least onememory. The processor implements the plurality of interface protocols asa software application for interfacing and communicating with theplurality of external destinations including the one or more of theexternal devices and applications.

In one embodiment, the external devices and applications include, forexample, a printer, a facsimile, and a scanner. In one embodiment, thecomputer data administration system includes the capability to integratean image using software so that the image gets seamlessly replicated andtransmitted to at least one of other devices and applications, and viathe Internet. In one embodiment, the computer data administration systemincludes the capability to integrate the electronic images into adestination application without the need to modify the destinationapplication.

In one embodiment, the computer data administration system includes aninterface that enables copying images between physical devices,applications, and the Internet using a single “GO” operation. In oneembodiment, the computer data administration system includes thecapability of adding at least one of electronic document and paperprocessing with a single programming step.

In one embodiment, the software application includes at least one inputmodule managing data comprising at least one of paper and electronicpaper input to the computer data administration system, and managing atleast one imaging device to input the data through at least one of ascanner and a digital copier, and managing the electronic paper from atleast one third-party software applications; at least one output modulemanaging the data output from the computer data administration system,managing at least one imaging device to output the data to at least oneof a standard Windows printer, an image printer, and a digital copier,and managing the output of the data to the third-party softwareapplication; at least one process module applying at least one dataprocessing to the data comprising the at least one of the paper and theelectronic paper as it is being copied, applying additionalfunctionality including at least one of workflow and processingfunctionality to the data comprising the at least one of paper andelectronic paper as it is being copied, and applying multiple processesto a single virtual copy; at least one client module presenting the datacomprising the at least one of paper and electronic paper as it is beingcopied, and information related to at least one of the input and outputfunctions; and at least one server module communicable with said atleast one input, output, client, and process modules and externalapplications, and capable of dynamically combining the externalapplications with at least one of digital capturing devices and digitalimaging devices.

In one embodiment, one or more of the external devices and applicationsintegrates the computer data administration system into an externalapplication via one of running the computer data administration system,as an external service and embedding the computer data administrationsystem as an embedded service.

In one embodiment, the server module includes enable virtual copyoperation means for initiating, canceling, and resetting said computerdata administration system; maintain list of available module means formaintaining a registry containing a list of said input, output, andprocess modules that can be used in said computer data administrationsystem, said list being read on startup, and maintaining another copy ofsaid list in a modules object accessible by said input, output, client,process and server modules; maintain currently active modules means formaintaining said input, output, and process modules currently being usedfor a current computer data administration system copy operation in aprogram object, and saving the currently active modules in a processtemplate file; and maintain complete document information means formaintaining information regarding a current file being copied, andsaving the information in a document template file.

In one embodiment, the server module includes at least one server moduleapplication programmer interface (API). In one embodiment, the servermodule application programmer interface (API) comprises the COM-basedinterfaces: at least one modules object maintaining a first list ofavailable input, output, and process modules; at least one programobject maintaining a second list of currently selected input, output,and process modules; at least one document object maintaininginformation regarding a current document being copied; at least onesystem administration method object used to initiate, cancel, and resetsaid computer data administration system; and at least one systemadministration event object used to provide feedback to the ClientModule.

In one embodiment, a computer data administration system includes atleast one of an electronic image, graphics and document administrationsystem capable of transmitting at least one of an electronic image,electronic graphics and electronic document to a plurality of externaldestinations including one or more of external devices and applicationsresponsively connectable at least one of locally and via the Internet.The computer data administration system comprises: a first capability tointegrate an image using software so that the image gets seamlesslyreplicated into at least one of other devices and applications, and viathe Internet; a second capability to integrate electronic images intoexisting applications without the need to modify the destinationapplication; an interface comprising a software application that enablescopying images between physical devices, applications, and the Internetusing a single “GO” operation; and a third capability of adding at leastone of electronic document and paper processing with a singleprogramming step.

A computer data administration system capable of managing andtransmitting at least one of an electronic image, electronic graphicsand electronic document to a plurality of external destinationsincluding one or more of external devices and applications at least oneof locally and via the Internet. The computer data administration systemincludes at least one memory storing at least one of a common anduniversal interface protocol for interfacing and communicating; and atleast one processor responsively connectable to said at least onememory, and implementing the at least one common and universal interfaceprotocol as a software application for interfacing and communicatingwith the plurality of external destinations including the one or more ofthe external devices and applications.

In one embodiment, a computer readable tangible medium storesinstructions for implementing a process driven by a computer implementedon at least one of an electronic image, graphics and documentadministration system capable of managing and transmitting at least oneof an electronic image, electronic graphics and electronic document to aplurality of external destinations including at least one of an externaldevice and application at least one of locally and via the Internet. Theinstructions control the computer to perform the process of: storing atleast one of a common and universal interface protocol for interfacingand communicating in at least one memory; and implementing the at leastone of common and universal interface protocol as a software applicationvia at least one processor for interfacing and communicating with theplurality of external destinations including the at least one externaldevice and application.

In one embodiment, a computer data administration system includes atleast one of an electronic image, graphics and document administrationsystem capable of transmitting at least one of an electronic image,electronic graphics and electronic document to a plurality of externaldestinations including one or more of external devices and applicationsresponsively connectable at least one of locally and via the Internet.The computer data administration system includes a single function copyoperation linking devices, applications and the Internet including atleast one a go operation, a single function paper copy between devicesand software applications, and a single function paper copy betweensoftware applications and devices; a one step programming method to addpaper support to electronic business processes including at least one ofa one step method of supporting paper within electronic business processapplication optionally including legacy systems with no or minimalreprogramming of the electronic business process application, a methodof recreating a module oriented copier in software; and a copierinterface implemented as software application including at least one ofa virtual copier interface method of presenting to a user an operationof at least one of copying files and electronic images, at least one ofto and from, at least one of digital imaging devices and softwareapplications, in a substantially single step, and presenting users withdirect access to at least one of tutorial and options from a mainapplication window.

In one embodiment, a server module includes enable virtual copyoperation means for initiating, canceling, and resetting said computerdata administration system; maintain list of available module means formaintaining a registry containing a list of said input, output, andprocess modules that can be used in said computer data administrationsystem, said list being read on startup, and maintaining another copy ofsaid list in a modules object accessible by said input, output, client,process and server modules; maintain currently active modules means formaintaining said input, output, and process modules currently being usedfor a current computer data administration system copy operation in aprogram object, and saving the currently active modules in a processtemplate file; and maintain complete document information means formaintaining information regarding a current file being copied, andsaving the information in a document template file.

In one embodiment, a computer data administration method includes atleast one of an electronic image, graphics and document administrationsystem capable of transmitting at least one of an electronic image,electronic graphics and electronic document to a plurality of externaldestinations including one or more of external devices and applicationsresponsively connectable at least one of locally and via the Internet.The method comprises the steps of integrating an image using software sothat the image gets seamlessly replicated into at least one of otherdevices and applications, and via the Internet; integrating electronicimages into existing applications without the need to modify thedestination application; interfacing via a software application enablingcopying images between physical devices, applications, and the Internetusing a single “GO” operation; and adding at least one of electronicdocument and paper processing with a single programming step.

In one embodiment, a server method includes initiating, canceling, andresetting said computer data administration system; maintaining aregistry containing a list of said input, output, and process modulesthat can be used in said computer data administration system, said listbeing read on startup, and maintaining another copy of said list in amodules object accessible by said input, output, client, process andserver modules; maintaining said input, output, and process modulescurrently being used for a current computer data administration systemcopy operation in a program object, and saving the currently activemodules in a process template file; and maintaining informationregarding a current file being copied, and saving the information in adocument template file.

A computer information management system includes at least one of anelectronic image, graphics and document management system capable oftransmitting at least one of an electronic image, electronic graphicsand electronic document to a plurality of external destinationsincluding one or more of external devices and applications. The computerinformation management system is responsively connectable at least oneof locally and via the Internet, and includes at least one storagestoring a plurality of interface protocols for interfacing andcommunicating, and at least one processor responsively connectable tothe at least one storage. The processor implements the plurality ofinterface protocols as a software application for interfacing andcommunicating with the plurality of external destinations including theone or more of the external devices and applications.

In one embodiment, the external devices and applications include, forexample, a printer, a facsimile, and a scanner. In one embodiment, thecomputer information management system includes the capability tointegrate an image using software so that the image gets seamlesslyreplicated and transmitted to at least one of other devices andapplications, and via the Internet. In one embodiment, the computerinformation management system includes the capability to integrate theelectronic images into a destination application without the need tomodify the destination application.

In one embodiment, the computer information management system includesan interface that enables copying images between physical devices,applications, and the Internet using a single “GO” operation. In oneembodiment, the computer information management system includes thecapability of adding at least one of electronic document and paperprocessing with a single programming step.

In one embodiment, the software application includes at least one inputmodule managing information comprising at least one of paper andelectronic paper input to the computer information management system,and managing at least one imaging device to input the informationthrough at least one of a scanner and a digital copier, and managing theelectronic paper from at least one third-party software applications; atleast one output module managing the information output from thecomputer information management system, managing at least one imagingdevice to output the information to at least one of a standard Windowsprinter, an image printer, and a digital copier, and managing the outputof the information to the third-party software application; at least oneprocess module applying at least one information processing to theinformation comprising the at least one of the paper and the electronicpaper as it is being copied, applying additional functionality includingat least one of workflow and processing functionality to the informationcomprising the at least one of paper and electronic paper as it is beingcopied, and applying multiple processes to a single virtual copy; atleast one client module presenting the information comprising the atleast one of paper and electronic paper as it is being copied, andinformation related to at least one of the input and output functions;and at least one server module communicable with said at least oneinput, output, client, and process modules and external applications,and capable of dynamically combining the external applications with atleast one of digital capturing devices and digital imaging devices.

In one embodiment, one or more of the external devices and applicationsintegrates the computer information management system into an externalapplication via one of running the computer information managementsystem, as an external service and embedding the computer informationmanagement system as an embedded service.

In one embodiment, the server module includes enable virtual copyoperation means for initiating, canceling, and resetting said computerinformation management system; maintain list of available module meansfor maintaining a registry containing a list of said input, output, andprocess modules that can be used in said computer information managementsystem, said list being read on startup, and maintaining another copy ofsaid list in a modules object accessible by said input, output, client,process and server modules; maintain currently active modules means formaintaining said input, output, and process modules currently being usedfor a current computer information management system copy operation in aprogram object, and saving the currently active modules in a processtemplate file; and maintain complete document information means formaintaining information regarding a current file being copied, andsaving the information in a document template file.

In one embodiment, the server module includes at least one server moduleapplication programmer interface (API). In one embodiment, the servermodule application programmer interface (API) comprises the COM-basedinterfaces: at least one modules object maintaining a first list ofavailable input, output, and process modules; at least one programobject maintaining a second list of currently selected input, output,and process modules; at least one document object maintaininginformation regarding a current document being copied; at least onesystem management method object used to initiate, cancel, and reset saidcomputer information management system; and at least one systemmanagement event object used to provide feedback to the Client Module.

In one embodiment, a computer information management system includes atleast one of an electronic image, graphics and document managementsystem capable of transmitting at least one of an electronic image,electronic graphics and electronic document to a plurality of externaldestinations including one or more of external devices and applicationsresponsively connectable at least one of locally and via the Internet.The computer information management system comprises:

a first capability to integrate an image using software so that theimage gets seamlessly replicated into at least one of other devices andapplications, and via the Internet; a second capability to integrateelectronic images into existing applications without the need to modifythe destination application; an interface comprising a softwareapplication that enables copying images between physical devices,applications, and the Internet using a single “GO” operation; and athird capability of adding at least one of electronic document and paperprocessing with a single programming step.

A computer information management system capable of managing andtransmitting at least one of an electronic image, electronic graphicsand electronic document to a plurality of external destinationsincluding one or more of external devices and applications at least oneof locally and via the Internet. The computer information managementsystem includes at least one storage storing at least one of a commonand universal interface protocol for interfacing and communicating; andat least one processor responsively connectable to said at least onestorage, and implementing the at least one common and universalinterface protocol as a software application for interfacing andcommunicating with the plurality of external destinations including theone or more of the external devices and applications.

In one embodiment, a computer readable tangible medium storesinstructions for implementing a process driven by a computer implementedon at least one of an electronic image, graphics and document managementsystem capable of managing and transmitting at least one of anelectronic image, electronic graphics and electronic document to aplurality of external destinations including at least one of an externaldevice and application at least one of locally and via the Internet. Theinstructions control the computer to perform the process of: storing atleast one of a common and universal interface protocol for interfacingand communicating in at least one storage; and implementing the at leastone of common and universal interface protocol as a software applicationvia at least one processor for interfacing and communicating with theplurality of external destinations including the at least one externaldevice and application.

In one embodiment, a computer information management system includes atleast one of an electronic image, graphics and document managementsystem capable of transmitting at least one of an electronic image,electronic graphics and electronic document to a plurality of externaldestinations including one or more of external devices and applicationsresponsively connectable at least one of locally and via the Internet.The computer information management system includes a single functioncopy operation linking devices, applications and the Internet includingat least one a go operation, a single function paper copy betweendevices and software applications, and a single function paper copybetween software applications and devices; a one step programming methodto add paper support to electronic business processes including at leastone of a one step method of supporting paper within electronic businessprocess application optionally including legacy systems with no orminimal reprogramming of the electronic business process application, amethod of recreating a module oriented copier in software; and a copierinterface implemented as software application including at least one ofa virtual copier interface method of presenting to a user an operationof at least one of copying files and electronic images, at least one ofto and from, at least one of digital imaging devices and softwareapplications, in a substantially single step, and presenting users withdirect access to at least one of tutorial and options from a mainapplication window.

In one embodiment, a server module includes enable virtual copyoperation means for initiating, canceling, and resetting said computerinformation management system; maintain list of available module meansfor maintaining a registry containing a list of said input, output, andprocess modules that can be used in said computer information managementsystem, said list being read on startup, and maintaining another copy ofsaid list in a modules object accessible by said input, output, client,process and server modules; maintain currently active modules means formaintaining said input, output, and process modules currently being usedfor a current computer information management system copy operation in aprogram object, and saving the currently active modules in a processtemplate file; and maintain complete document information means formaintaining information regarding a current file being copied, andsaving the information in a document template file.

In one embodiment, a computer information management method includes atleast one of an electronic image, graphics and document managementsystem capable of transmitting at least one of an electronic image,electronic graphics and electronic document to a plurality of externaldestinations including one or more of external devices and applicationsresponsively connectable at least one of locally and via the Internet.The method comprises the steps of integrating an image using software sothat the image gets seamlessly replicated into at least one of otherdevices and applications, and via the Internet; integrating electronicimages into existing applications without the need to modify thedestination application; interfacing via a software application enablingcopying images between physical devices, applications, and the Internetusing a single “GO” operation; and adding at least one of electronicdocument and paper processing with a single programming step.

In one embodiment, a server method includes initiating, canceling, andresetting said computer information management system; maintaining aregistry containing a list of said input, output, and process modulesthat can be used in said computer information management system, saidlist being read on startup, and maintaining another copy of said list ina modules object accessible by said input, output, client, process andserver modules; maintaining said input, output, and process modulescurrently being used for a current computer information managementsystem copy operation in a program object, and saving the currentlyactive modules in a process template file; and maintaining informationregarding a current file being copied, and saving the information in adocument template file.

A computer data management system includes at least one of an electronicimage, graphics and document management system capable of transmittingat least one of an electronic image, electronic graphics and electronicdocument to a plurality of external destinations including one or moreof external devices and applications. The computer data managementsystem is responsively connectable at least one of locally and via theInternet, and includes at least one memory storing a plurality ofinterface protocols for interfacing and communicating, and at least oneprocessor responsively connectable to the at least one memory. Theprocessor implements at least one interface protocol as a softwareapplication for interfacing and communicating with the plurality ofexternal destinations including the one or more of the external devicesand applications.

In one embodiment, the external devices and applications include, forexample, a printer, a facsimile, and a scanner. In one embodiment, thecomputer data management system includes the capability to integrate animage using software so that the image gets seamlessly replicated andtransmitted to at least one of other devices and applications, and viathe Internet. In one embodiment, the computer data management systemincludes the capability to integrate the electronic images into adestination application without the need to modify the destinationapplication.

In one embodiment, the computer data management system includes anoptional interface that enables copying images between physical devices,applications, and the Internet using a single “GO” operation. In oneembodiment, the computer data management system includes the optionalcapability of adding at least one of electronic document and paperprocessing with a single programming step.

In one embodiment, the software application includes one or more of: atleast one input module managing data comprising at least one of paperand electronic paper input to the computer data management system, andmanaging at least one imaging device to input the data through at leastone of a scanner and a digital copier, and managing the electronic paperfrom at least one third-party software applications; at least one outputmodule managing the data output from the computer data managementsystem, managing at least one imaging device to output the data to atleast one of a standard Windows printer, an image printer, and a digitalcopier, and managing the output of the data to the third-party softwareapplication; at least one process module applying at least one dataprocessing to the data comprising the at least one of the paper and theelectronic paper as it is being copied, applying additionalfunctionality including at least one of workflow and processingfunctionality to the data comprising the at least one of paper andelectronic paper as it is being copied, and applying multiple processesto a single virtual copy; at least one client module presenting the datacomprising the at least one of paper and electronic paper as it is beingcopied, and information related to at least one of the input and outputfunctions; and at least one server module communicable with said atleast one input, output, client, and process modules and externalapplications, and capable of dynamically combining the externalapplications with at least one of digital capturing devices and digitalimaging devices.

In one embodiment, one or more of the external devices and applicationsintegrates the computer data management system into an externalapplication via at least one of running the computer data managementsystem, as an external service and embedding the computer datamanagement system as an embedded service.

In one embodiment, the server module includes one or more of: enablevirtual copy operation means for initiating, canceling, and resettingsaid computer data management system; maintain list of available modulemeans for maintaining a registry containing a list of said input,output, and process modules that can be used in said computer datamanagement system, said list being read on startup, and maintaininganother copy of said list in a modules object accessible by said input,output, client, process and server modules; maintain currently activemodules means for maintaining said input, output, and process modulescurrently being used for a current computer data management system copyoperation in a program object, and saving the currently active modulesin a process template file; and maintain complete document informationmeans for maintaining information regarding a current file being copied,and saving the information in a document template file.

In one embodiment, the server module includes at least one server moduleapplication programmer interface (API). In one embodiment, the servermodule application programmer interface (API) comprises one or more ofthe following COM-based interfaces: at least one modules objectmaintaining a first list of available input, output, and processmodules; at least one program object maintaining a second list ofcurrently selected input, output, and process modules; at least onedocument object maintaining information regarding a current documentbeing copied; at least one system management method object used toinitiate, cancel, and reset said computer data management system; and atleast one system management event object used to provide feedback to theClient Module.

In one embodiment, a computer data management system includes at leastone of an electronic image, graphics and document management systemcapable of transmitting at least one of an electronic image, electronicgraphics and electronic document to a plurality of external destinationsincluding one or more of external devices and applications responsivelyconnectable at least one of locally and via the Internet. The computerdata management system comprises one or more of: a first capability tointegrate an image using software so that the image gets seamlesslyreplicated into at least one of other devices and applications, and viathe Internet; a second capability to integrate electronic images intoexisting applications without the need to modify the destinationapplication; an interface comprising a software application that enablescopying images between physical devices, applications, and the Internetusing a single “GO” operation; and a third capability of adding at leastone of electronic document and paper processing with a singleprogramming step.

A computer data management system capable of managing and transmittingat least one of an electronic image, electronic graphics and electronicdocument to a plurality of external destinations including one or moreof external devices and applications at least one of locally and via theInternet. The computer data management system includes at least onememory storing at least one of a common and universal interface protocolfor interfacing and communicating; and at least one data processorresponsively connectable to said at least one memory, and implementingthe at least one common and universal interface protocol as a softwareapplication for interfacing and communicating with the plurality ofexternal destinations including the one or more of the external devicesand applications.

In one embodiment, a computer readable tangible medium storesinstructions for implementing a process driven by a computer implementedon at least one of an electronic image, graphics and document managementsystem capable of managing and transmitting at least one of anelectronic image, electronic graphics and electronic document to aplurality of external destinations including at least one of an externaldevice and application at least one of locally and via the Internet. Theinstructions control the computer to perform the process of: storing atleast one of a common and universal interface protocol for interfacingand communicating in at least one memory; and implementing the at leastone of common and universal interface protocol interfacing andcommunicating with the plurality of external destinations.

In one embodiment, a computer data management system includes at leastone of an electronic image, graphics and document management systemcapable of transmitting at least one of an electronic image, electronicgraphics and electronic document to a plurality of external destinationsincluding one or more of external devices and applications responsivelyconnectable at least one of locally and via the Internet. The computerdata management system includes one or more of: a single function copyoperation linking devices, applications and the Internet including atleast one a go operation, a single function paper copy between devicesand software applications, and a single function paper copy betweensoftware applications and devices; a one step programming method to addpaper support to electronic business processes including at least one ofa one step method of supporting paper within electronic business processapplication optionally including legacy systems with no or minimalreprogramming of the electronic business process application, a methodof recreating a module oriented copier in software; and a copierinterface implemented as software application including at least one ofa virtual copier interface method of presenting to a user an operationof at least one of copying files and electronic images, at least one ofto and from, at least one of digital imaging devices and softwareapplications, in a substantially single step, and presenting users withdirect access to at least one of tutorial and options from a mainapplication window.

In one embodiment, a server module includes one or more of: enablevirtual copy operation means for initiating, canceling, and resettingsaid computer data management system; maintain list of available modulemeans for maintaining a registry containing a list of said input,output, and process modules that can be used in said computer datamanagement system, said list being read on startup, and maintaininganother copy of said list in a modules object accessible by said input,output, client, process and server modules; maintain currently activemodules means for maintaining said input, output, and process modulescurrently being used for a current computer data management system copyoperation in a program object, and saving the currently active modulesin a process template file; and maintain complete document informationmeans for maintaining information regarding a current file being copied,and saving the information in a document template file.

In one embodiment, a computer data management method includes at leastone of an electronic image, graphics and document management systemcapable of transmitting at least one of an electronic image, electronicgraphics and electronic document to a plurality of external destinationsincluding one or more of external devices and applications responsivelyconnectable at least one of locally and via the Internet. The methodcomprises one or more of the steps of integrating an image usingsoftware so that the image gets seamlessly replicated into at least oneof other devices and applications, and via the Internet; integratingelectronic images into existing applications without the need to modifythe destination application; interfacing via a software applicationenabling copying images between physical devices, applications, and theInternet using a single “GO” operation; and adding at least one ofelectronic document and paper processing with a single programming step.

In one embodiment, a server method includes one or more of: initiating,canceling, and resetting said computer data management system;maintaining a registry containing a list of said input, output, andprocess modules that can be used in said computer data managementsystem, said list being read on startup, and maintaining another copy ofsaid list in a modules object accessible by said input, output, client,process and server modules; maintaining said input, output, and processmodules currently being used for a current computer data managementsystem copy operation in a program object, and saving the currentlyactive modules in a process template file; and maintaining informationregarding a current file being copied, and saving the information in adocument template file.

A computer data administration system includes at least one of anelectronic image, graphics and document administration system capable oftransmitting at least one of an electronic image, electronic graphicsand electronic document to a plurality of external destinationsincluding one or more of external devices and applications. The computerdata administration system is responsively connectable at least one oflocally and via the Internet, and includes at least one memory storing aplurality of interface protocols for interfacing and communicating, andat least one processor responsively connectable to the at least onememory. The processor implements at least one interface protocol as asoftware application for interfacing and communicating with theplurality of external destinations including the one or more of theexternal devices and applications.

In one embodiment, the external devices and applications include, forexample, a printer, a facsimile, and a scanner. In one embodiment, thecomputer data administration system includes the capability to integratean image using software so that the image gets seamlessly replicated andtransmitted to at least one of other devices and applications, and viathe Internet. In one embodiment, the computer data administration systemincludes the capability to integrate the electronic images into adestination application without the need to modify the destinationapplication.

In one embodiment, the computer data administration system includes anoptional interface that enables copying images between physical devices,applications, and the Internet using a single “GO” operation. In oneembodiment, the computer data administration system includes theoptional capability of adding at least one of electronic document andpaper processing with a single programming step.

In one embodiment, the software application includes one or more of: atleast one input module managing data comprising at least one of paperand electronic paper input to the computer data administration system,and managing at least one imaging device to input the data through atleast one of a scanner and a digital copier, and managing the electronicpaper from at least one third-party software applications; at least oneoutput module managing the data output from the computer dataadministration system, managing at least one imaging device to outputthe data to at least one of a standard Windows printer, an imageprinter, and a digital copier, and managing the output of the data tothe third-party software application; at least one process moduleapplying at least one data processing to the data comprising the atleast one of the paper and the electronic paper as it is being copied,applying additional functionality including at least one of workflow andprocessing functionality to the data comprising the at least one ofpaper and electronic paper as it is being copied, and applying multipleprocesses to a single virtual copy; at least one client modulepresenting the data comprising the at least one of paper and electronicpaper as it is being copied, and information related to at least one ofthe input and output functions; and at least one server modulecommunicable with said at least one input, output, client, and processmodules and external applications, and capable of dynamically combiningthe external applications with at least one of digital capturing devicesand digital imaging devices.

In one embodiment, one or more of the external devices and applicationsintegrates the computer data administration system into an externalapplication via at least one of running the computer data administrationsystem, as an external service and embedding the computer dataadministration system as an embedded service.

In one embodiment, the server module includes one or more of: enablevirtual copy operation means for initiating, canceling, and resettingsaid computer data administration system; maintain list of availablemodule means for maintaining a registry containing a list of said input,output, and process modules that can be used in said computer dataadministration system, said list being read on startup, and maintaininganother copy of said list in a modules object accessible by said input,output, client, process and server modules; maintain currently activemodules means for maintaining said input, output, and process modulescurrently being used for a current computer data administration systemcopy operation in a program object, and saving the currently activemodules in a process template file; and maintain complete documentinformation means for maintaining information regarding a current filebeing copied, and saving the information in a document template file.

In one embodiment, the server module includes at least one server moduleapplication programmer interface (API). In one embodiment, the servermodule application programmer interface (API) comprises one or more ofthe following COM-based interfaces: at least one modules objectmaintaining a first list of available input, output, and processmodules; at least one program object maintaining a second list ofcurrently selected input, output, and process modules; at least onedocument object maintaining information regarding a current documentbeing copied; at least one system administration method object used toinitiate, cancel, and reset said computer data administration system;and at least one system administration event object used to providefeedback to the Client Module.

In one embodiment, a computer data administration system includes atleast one of an electronic image, graphics and document administrationsystem capable of transmitting at least one of an electronic image,electronic graphics and electronic document to a plurality of externaldestinations including one or more of external devices and applicationsresponsively connectable at least one of locally and via the Internet.The computer data administration system comprises one or more of: afirst capability to integrate an image using software so that the imagegets seamlessly replicated into at least one of other devices andapplications, and via the Internet; a second capability to integrateelectronic images into existing applications without the need to modifythe destination application; an interface comprising a softwareapplication that enables copying images between physical devices,applications, and the Internet using a single “GO” operation; and athird capability of adding at least one of electronic document and paperprocessing with a single programming step.

A computer data administration system capable of managing andtransmitting at least one of an electronic image, electronic graphicsand electronic document to a plurality of external destinationsincluding one or more of external devices and applications at least oneof locally and via the Internet. The computer data administration systemincludes at least one memory storing at least one of a common anduniversal interface protocol for interfacing and communicating; and atleast one data processor responsively connectable to said at least onememory, and implementing the at least one common and universal interfaceprotocol as a software application for interfacing and communicatingwith the plurality of external destinations including the one or more ofthe external devices and applications.

In one embodiment, a computer readable tangible medium storesinstructions for implementing a process driven by a computer implementedon at least one of an electronic image, graphics and documentadministration system capable of managing and transmitting at least oneof an electronic image, electronic graphics and electronic document to aplurality of external destinations including at least one of an externaldevice and application at least one of locally and via the Internet. Theinstructions control the computer to perform the process of: storing atleast one of a common and universal interface protocol for interfacingand communicating in at least one memory; and implementing the at leastone of common and universal interface protocol interfacing andcommunicating with the plurality of external destinations.

In one embodiment, a computer data administration system includes atleast one of an electronic image, graphics and document administrationsystem capable of transmitting at least one of an electronic image,electronic graphics and electronic document to a plurality of externaldestinations including one or more of external devices and applicationsresponsively connectable at least one of locally and via the Internet.The computer data administration system includes one or more of: asingle function copy operation linking devices, applications and theInternet including at least one a go operation, a single function papercopy between devices and software applications, and a single functionpaper copy between software applications and devices; a one stepprogramming method to add paper support to electronic business processesincluding at least one of a one step method of supporting paper withinelectronic business process application optionally including legacysystems with no or minimal reprogramming of the electronic businessprocess application, a method of recreating a module oriented copier insoftware; and a copier interface implemented as software applicationincluding at least one of a virtual copier interface method ofpresenting to a user an operation of at least one of copying files andelectronic images, at least one of to and from, at least one of digitalimaging devices and software applications, in a substantially singlestep, and presenting users with direct access to at least one oftutorial and options from a main application window.

In one embodiment, a server module includes one or more of: enablevirtual copy operation means for initiating, canceling, and resettingsaid computer data administration system; maintain list of availablemodule means for maintaining a registry containing a list of said input,output, and process modules that can be used in said computer dataadministration system, said list being read on startup, and maintaininganother copy of said list in a modules object accessible by said input,output, client, process and server modules; maintain currently activemodules means for maintaining said input, output, and process modulescurrently being used for a current computer data administration systemcopy operation in a program object, and saving the currently activemodules in a process template file; and maintain complete documentinformation means for maintaining information regarding a current filebeing copied, and saving the information in a document template file.

In one embodiment, a computer data administration method includes atleast one of an electronic image, graphics and document administrationsystem capable of transmitting at least one of an electronic image,electronic graphics and electronic document to a plurality of externaldestinations including one or more of external devices and applicationsresponsively connectable at least one of locally and via the Internet.The method comprises one or more of the steps of integrating an imageusing software so that the image gets seamlessly replicated into atleast one of other devices and applications, and via the Internet;integrating electronic images into existing applications without theneed to modify the destination application; interfacing via a softwareapplication enabling copying images between physical devices,applications, and the Internet using a single “GO” operation; and addingat least one of electronic document and paper processing with a singleprogramming step.

In one embodiment, a server method includes one or more of: initiating,canceling, and resetting said computer data administration system;maintaining a registry containing a list of said input, output, andprocess modules that can be used in said computer data administrationsystem, said list being read on startup, and maintaining another copy ofsaid list in a modules object accessible by said input, output, client,process and server modules; maintaining said input, output, and processmodules currently being used for a current computer data administrationsystem copy operation in a program object, and saving the currentlyactive modules in a process template file; and maintaining informationregarding a current file being copied, and saving the information in adocument template file.

A workstation data management system includes at least one of anelectronic image, graphics and document management system capable oftransmitting at least one of an electronic image, electronic graphicsand electronic document to a plurality of external destinationsincluding one or more of external devices and applications. Theworkstation data management system is responsively connectable at leastone of locally and via the Internet, and includes at least one memorystoring a plurality of interface protocols for interfacing andcommunicating, and at least one processor responsively connectable tothe at least one memory. The processor implements at least one interfaceprotocol as a software application for interfacing and communicatingwith the plurality of external destinations including the one or more ofthe external devices and applications.

In one embodiment, the external devices and applications include, forexample, a printer, a facsimile, and a scanner. In one embodiment, theworkstation data management system includes the capability to integratean image using software so that the image gets seamlessly replicated andtransmitted to at least one of other devices and applications, and viathe Internet. In one embodiment, the workstation data management systemincludes the capability to integrate the electronic images into adestination application without the need to modify the destinationapplication.

In one embodiment, the workstation data management system includes anoptional interface that enables copying images between physical devices,applications, and the Internet using a single “GO” operation. In oneembodiment, the workstation data management system includes the optionalcapability of adding at least one of electronic document and paperprocessing with a single programming step.

In one embodiment, the software application includes one or more of: atleast one input module managing data comprising at least one of paperand electronic paper input to the workstation data management system,and managing at least one imaging device to input the data through atleast one of a scanner and a digital copier, and managing the electronicpaper from at least one third-party software applications; at least oneoutput module managing the data output from the workstation datamanagement system, managing at least one imaging device to output thedata to at least one of a standard Windows printer, an image printer,and a digital copier, and managing the output of the data to thethird-party software application; at least one process module applyingat least one data processing to the data comprising the at least one ofthe paper and the electronic paper as it is being copied, applyingadditional functionality including at least one of workflow andprocessing functionality to the data comprising the at least one ofpaper and electronic paper as it is being copied, and applying multipleprocesses to a single virtual copy; at least one client modulepresenting the data comprising the at least one of paper and electronicpaper as it is being copied, and information related to at least one ofthe input and output functions; and at least one server modulecommunicable with said at least one input, output, client, and processmodules and external applications, and capable of dynamically combiningthe external applications with at least one of digital capturing devicesand digital imaging devices.

In one embodiment, one or more of the external devices and applicationsintegrates the workstation data management system into an externalapplication via at least one of running the workstation data managementsystem, as an external service and embedding the workstation datamanagement system as an embedded service.

In one embodiment, the server module includes one or more of: enablevirtual copy operation means for initiating, canceling, and resettingsaid workstation data management system; maintain list of availablemodule means for maintaining a registry containing a list of said input,output, and process modules that can be used in said workstation datamanagement system, said list being read on startup, and maintaininganother copy of said list in a modules object accessible by said input,output, client, process and server modules; maintain currently activemodules means for maintaining said input, output, and process modulescurrently being used for a current workstation data management systemcopy operation in a program object, and saving the currently activemodules in a process template file; and maintain complete documentinformation means for maintaining information regarding a current filebeing copied, and saving the information in a document template file.

In one embodiment, the server module includes at least one server moduleapplication programmer interface (API). In one embodiment, the servermodule application programmer interface (API) comprises one or more ofthe following COM-based interfaces: at least one modules objectmaintaining a first list of available input, output, and processmodules; at least one program object maintaining a second list ofcurrently selected input, output, and process modules; at least onedocument object maintaining information regarding a current documentbeing copied; at least one system management method object used toinitiate, cancel, and reset said workstation data management system; andat least one system management event object used to provide feedback tothe Client Module.

In one embodiment, a workstation data management system includes atleast one of an electronic image, graphics and document managementsystem capable of transmitting at least one of an electronic image,electronic graphics and electronic document to a plurality of externaldestinations including one or more of external devices and applicationsresponsively connectable at least one of locally and via the Internet.The workstation data management system comprises one or more of: a firstcapability to integrate an image using software so that the image getsseamlessly replicated into at least one of other devices andapplications, and via the Internet; a second capability to integrateelectronic images into existing applications without the need to modifythe destination application; an interface comprising a softwareapplication that enables copying images between physical devices,applications, and the Internet using a single “GO” operation; and athird capability of adding at least one of electronic document and paperprocessing with a single programming step.

A workstation data management system capable of managing andtransmitting at least one of an electronic image, electronic graphicsand electronic document to a plurality of external destinationsincluding one or more of external devices and applications at least oneof locally and via the Internet. The workstation data management systemincludes at least one memory storing at least one of a common anduniversal interface protocol for interfacing and communicating; and atleast one data processor responsively connectable to said at least onememory, and implementing the at least one common and universal interfaceprotocol as a software application for interfacing and communicatingwith the plurality of external destinations including the one or more ofthe external devices and applications.

In one embodiment, a workstation readable tangible medium storesinstructions for implementing a process driven by a workstationimplemented on at least one of an electronic image, graphics anddocument management system capable of managing and transmitting at leastone of an electronic image, electronic graphics and electronic documentto a plurality of external destinations including at least one of anexternal device and application at least one of locally and via theInternet. The instructions control the workstation to perform theprocess of: storing at least one of a common and universal interfaceprotocol for interfacing and communicating in at least one memory; andimplementing the at least one of common and universal interface protocolinterfacing and communicating with the plurality of externaldestinations.

In one embodiment, a workstation data management system includes atleast one of an electronic image, graphics and document managementsystem capable of transmitting at least one of an electronic image,electronic graphics and electronic document to a plurality of externaldestinations including one or more of external devices and applicationsresponsively connectable at least one of locally and via the Internet.The workstation data management system includes one or more of: a singlefunction copy operation linking devices, applications and the Internetincluding at least one a go operation, a single function paper copybetween devices and software applications, and a single function papercopy between software applications and devices; a one step programmingmethod to add paper support to electronic business processes includingat least one of a one step method of supporting paper within electronicbusiness process application optionally including legacy systems with noor minimal reprogramming of the electronic business process application,a method of recreating a module oriented copier in software; and acopier interface implemented as software application including at leastone of a virtual copier interface method of presenting to a user anoperation of at least one of copying files and electronic images, atleast one of to and from, at least one of digital imaging devices andsoftware applications, in a substantially single step, and presentingusers with direct access to at least one of tutorial and options from amain application window.

In one embodiment, a server module includes one or more of: enablevirtual copy operation means for initiating, canceling, and resettingsaid workstation data management system; maintain list of availablemodule means for maintaining a registry containing a list of said input,output, and process modules that can be used in said workstation datamanagement system, said list being read on startup, and maintaininganother copy of said list in a modules object accessible by said input,output, client, process and server modules; maintain currently activemodules means for maintaining said input, output, and process modulescurrently being used for a current workstation data management systemcopy operation in a program object, and saving the currently activemodules in a process template file; and maintain complete documentinformation means for maintaining information regarding a current filebeing copied, and saving the information in a document template file.

In one embodiment, a workstation data management method includes atleast one of an electronic image, graphics and document managementsystem capable of transmitting at least one of an electronic image,electronic graphics and electronic document to a plurality of externaldestinations including one or more of external devices and applicationsresponsively connectable at least one of locally and via the Internet.The method comprises one or more of the steps of integrating an imageusing software so that the image gets seamlessly replicated into atleast one of other devices and applications, and via the Internet;integrating electronic images into existing applications without theneed to modify the destination application; interfacing via a softwareapplication enabling copying images between physical devices,applications, and the Internet using a single “GO” operation; and addingat least one of electronic document and paper processing with a singleprogramming step.

In one embodiment, a server method includes one or more of: initiating,canceling, and resetting said workstation data management system;maintaining a registry containing a list of said input, output, andprocess modules that can be used in said workstation data managementsystem, said list being read on startup, and maintaining another copy ofsaid list in a modules object accessible by said input, output, client,process and server modules; maintaining said input, output, and processmodules currently being used for a current workstation data managementsystem copy operation in a program object, and saving the currentlyactive modules in a process template file; and maintaining informationregarding a current file being copied, and saving the information in adocument template file.

A computer data management apparatus includes at least one of anelectronic image, graphics and document management apparatus capable oftransmitting at least one of an electronic image, electronic graphicsand electronic document to a plurality of external destinationsincluding one or more of external devices and applications. The computerdata management apparatus is responsively connectable at least one oflocally and via the Internet, and includes at least one memory storing aplurality of interface protocols for interfacing and communicating, andat least one processor responsively connectable to the at least onememory. The processor implements at least one interface protocol as asoftware application for interfacing and communicating with theplurality of external destinations including the one or more of theexternal devices and applications.

In one embodiment, the external devices and applications include, forexample, a printer, a facsimile, and a scanner. In one embodiment, thecomputer data management apparatus includes the capability to integratean image using software so that the image gets seamlessly replicated andtransmitted to at least one of other devices and applications, and viathe Internet. In one embodiment, the computer data management apparatusincludes the capability to integrate the electronic images into adestination application without the need to modify the destinationapplication.

In one embodiment, the computer data management apparatus includes anoptional interface that enables copying images between physical devices,applications, and the Internet using a single “GO” operation. In oneembodiment, the computer data management apparatus includes the optionalcapability of adding at least one of electronic document and paperprocessing with a single programming step.

In one embodiment, the software application includes one or more of: atleast one input module managing data comprising at least one of paperand electronic paper input to the computer data management apparatus,and managing at least one imaging device to input the data through atleast one of a scanner and a digital copier, and managing the electronicpaper from at least one third-party software applications; at least oneoutput module managing the data output from the computer data managementapparatus, managing at least one imaging device to output the data to atleast one of a standard Windows printer, an image printer, and a digitalcopier, and managing the output of the data to the third-party softwareapplication; at least one process module applying at least one dataprocessing to the data comprising the at least one of the paper and theelectronic paper as it is being copied, applying additionalfunctionality including at least one of workflow and processingfunctionality to the data comprising the at least one of paper andelectronic paper as it is being copied, and applying multiple processesto a single virtual copy; at least one client module presenting the datacomprising the at least one of paper and electronic paper as it is beingcopied, and information related to at least one of the input and outputfunctions; and at least one server module communicable with said atleast one input, output, client, and process modules and externalapplications, and capable of dynamically combining the externalapplications with at least one of digital capturing devices and digitalimaging devices.

In one embodiment, one or more of the external devices and applicationsintegrates the computer data management apparatus into an externalapplication via at least one of running the computer data managementapparatus, as an external service and embedding the computer datamanagement apparatus as an embedded service.

In one embodiment, the server module includes one or more of: enablevirtual copy operation means for initiating, canceling, and resettingsaid computer data management apparatus; maintain list of availablemodule means for maintaining a registry containing a list of said input,output, and process modules that can be used in said computer datamanagement apparatus, said list being read on startup, and maintaininganother copy of said list in a modules object accessible by said input,output, client, process and server modules; maintain currently activemodules means for maintaining said input, output, and process modulescurrently being used for a current computer data management apparatuscopy operation in a program object, and saving the currently activemodules in a process template file; and maintain complete documentinformation means for maintaining information regarding a current filebeing copied, and saving the information in a document template file.

In one embodiment, the server module includes at least one server moduleapplication programmer interface (API). In one embodiment, the servermodule application programmer interface (API) comprises one or more ofthe following COM-based interfaces: at least one modules objectmaintaining a first list of available input, output, and processmodules; at least one program object maintaining a second list ofcurrently selected input, output, and process modules; at least onedocument object maintaining information regarding a current documentbeing copied; at least one apparatus management method object used toinitiate, cancel, and reset said computer data management apparatus; andat least one apparatus management event object used to provide feedbackto the Client Module.

In one embodiment, a computer data management apparatus includes atleast one of an electronic image, graphics and document managementapparatus capable of transmitting at least one of an electronic image,electronic graphics and electronic document to a plurality of externaldestinations including one or more of external devices and applicationsresponsively connectable at least one of locally and via the Internet.The computer data management apparatus comprises one or more of: a firstcapability to integrate an image using software so that the image getsseamlessly replicated into at least one of other devices andapplications, and via the Internet; a second capability to integrateelectronic images into existing applications without the need to modifythe destination application; an interface comprising a softwareapplication that enables copying images between physical devices,applications, and the Internet using a single “GO” operation; and athird capability of adding at least one of electronic document and paperprocessing with a single programming step.

A computer data management apparatus capable of managing andtransmitting at least one of an electronic image, electronic graphicsand electronic document to a plurality of external destinationsincluding one or more of external devices and applications at least oneof locally and via the Internet. The computer data management apparatusincludes at least one memory storing at least one of a common anduniversal interface protocol for interfacing and communicating; and atleast one data processor responsively connectable to said at least onememory, and implementing the at least one common and universal interfaceprotocol as a software application for interfacing and communicatingwith the plurality of external destinations including the one or more ofthe external devices and applications.

In one embodiment, a computer readable tangible medium storesinstructions for implementing a process driven by a computer implementedon at least one of an electronic image, graphics and document managementapparatus capable of managing and transmitting at least one of anelectronic image, electronic graphics and electronic document to aplurality of external destinations including at least one of an externaldevice and application at least one of locally and via the Internet. Theinstructions control the computer to perform the process of: storing atleast one of a common and universal interface protocol for interfacingand communicating in at least one memory; and implementing the at leastone of common and universal interface protocol interfacing andcommunicating with the plurality of external destinations.

In one embodiment, a computer data management apparatus includes atleast one of an electronic image, graphics and document managementapparatus capable of transmitting at least one of an electronic image,electronic graphics and electronic document to a plurality of externaldestinations including one or more of external devices and applicationsresponsively connectable at least one of locally and via the Internet.The computer data management apparatus includes one or more of: a singlefunction copy operation linking devices, applications and the Internetincluding at least one a go operation, a single function paper copybetween devices and software applications, and a single function papercopy between software applications and devices; a one step programmingmethod to add paper support to electronic business processes includingat least one of a one step method of supporting paper within electronicbusiness process application optionally including legacy apparatus withno or minimal reprogramming of the electronic business processapplication, a method of recreating a module oriented copier insoftware; and a copier interface implemented as software applicationincluding at least one of a virtual copier interface method ofpresenting to a user an operation of at least one of copying files andelectronic images, at least one of to and from, at least one of digitalimaging devices and software applications, in a substantially singlestep, and presenting users with direct access to at least one oftutorial and options from a main application window.

In one embodiment, a server module includes one or more of: enablevirtual copy operation means for initiating, canceling, and resettingsaid computer data management apparatus; maintain list of availablemodule means for maintaining a registry containing a list of said input,output, and process modules that can be used in said computer datamanagement apparatus, said list being read on startup, and maintaininganother copy of said list in a modules object accessible by said input,output, client, process and server modules; maintain currently activemodules means for maintaining said input, output, and process modulescurrently being used for a current computer data management apparatuscopy operation in a program object, and saving the currently activemodules in a process template file; and maintain complete documentinformation means for maintaining information regarding a current filebeing copied, and saving the information in a document template file.

In one embodiment, a computer data management method includes at leastone of an electronic image, graphics and document management apparatuscapable of transmitting at least one of an electronic image, electronicgraphics and electronic document to a plurality of external destinationsincluding one or more of external devices and applications responsivelyconnectable at least one of locally and via the Internet. The methodcomprises one or more of the steps of integrating an image usingsoftware so that the image gets seamlessly replicated into at least oneof other devices and applications, and via the Internet; integratingelectronic images into existing applications without the need to modifythe destination application; interfacing via a software applicationenabling copying images between physical devices, applications, and theInternet using a single “GO” operation; and adding at least one ofelectronic document and paper processing with a single programming step.

In one embodiment, a server method includes one or more of: initiating,canceling, and resetting said computer data management apparatus;maintaining a registry containing a list of said input, output, andprocess modules that can be used in said computer data managementapparatus, said list being read on startup, and maintaining another copyof said list in a modules object accessible by said input, output,client, process and server modules; maintaining said input, output, andprocess modules currently being used for a current computer datamanagement apparatus copy operation in a program object, and saving thecurrently active modules in a process template file; and maintaininginformation regarding a current file being copied, and saving theinformation in a document template file.

A computer data management device includes at least one of an electronicimage, graphics and document management device capable of transmittingat least one of an electronic image, electronic graphics and electronicdocument to a plurality of external destinations including one or moreof external devices and applications. The computer data managementdevice is responsively connectable at least one of locally and via theInternet, and includes at least one memory storing a plurality ofinterface procedures for communicating and communicating, and at leastone processor responsively connectable to the at least one memory. Theprocessor implements at least one interface procedure as a softwareapplication for communicating and communicating with the plurality ofexternal destinations including the one or more of the external devicesand applications.

In one embodiment, the external devices and applications include, forexample, a printer, a facsimile, and a scanner. In one embodiment, thecomputer data management device includes the capability to integrate animage using software so that the image gets seamlessly replicated andtransmitted to at least one of other devices and applications, and viathe Internet. In one embodiment, the computer data management deviceincludes the capability to integrate the electronic images into adestination application without the need to modify the destinationapplication.

In one embodiment, the computer data management device includes anoptional interface that enables copying images between physical devices,applications, and the Internet using a single “GO” action. In oneembodiment, the computer data management device includes the optionalcapability of adding at least one of electronic document and paperprocessing with a single programming step.

In one embodiment, the software application includes one or more of: atleast one input module managing data comprising at least one of paperand electronic paper input to the computer data management device, andmanaging at least one imaging device to input the data through at leastone of a scanner and a digital copier, and managing the electronic paperfrom at least one third-party software applications; at least one outputmodule managing the data output from the computer data managementdevice, managing at least one imaging device to output the data to atleast one of a standard Windows printer, an image printer, and a digitalcopier, and managing the output of the data to the third-party softwareapplication; at least one process module applying at least one dataprocessing to the data comprising the at least one of the paper and theelectronic paper as it is being copied, applying additionalfunctionality including at least one of workflow and processingfunctionality to the data comprising the at least one of paper andelectronic paper as it is being copied, and applying multiple processesto a single virtual copy; at least one client module presenting the datacomprising the at least one of paper and electronic paper as it is beingcopied, and information related to at least one of the input and outputfunctions; and at least one server module communicable with said atleast one input, output, client, and process modules and externalapplications, and capable of dynamically combining the externalapplications with at least one of digital capturing devices and digitalimaging devices.

In one embodiment, one or more of the external devices and applicationsintegrates the computer data management device into an externalapplication via at least one of running the computer data managementdevice, as an external service and embedding the computer datamanagement device as an embedded service.

In one embodiment, the server module includes one or more of: enablevirtual copy action means for initiating, canceling, and resetting saidcomputer data management device; maintain list of available module meansfor maintaining a registry containing a list of said input, output, andprocess modules that can be used in said computer data managementdevice, said list being read on startup, and maintaining another copy ofsaid list in a modules object accessible by said input, output, client,process and server modules; maintain currently active modules means formaintaining said input, output, and process modules currently being usedfor a current computer data management device copy action in a programobject, and saving the currently active modules in a process templatefile; and maintain complete document information means for maintaininginformation regarding a current file being copied, and saving theinformation in a document template file.

In one embodiment, the server module includes at least one server moduleapplication programmer interface (API). In one embodiment, the servermodule application programmer interface (API) comprises one or more ofthe following COM-based interfaces: at least one modules objectmaintaining a first list of available input, output, and processmodules; at least one program object maintaining a second list ofcurrently selected input, output, and process modules; at least onedocument object maintaining information regarding a current documentbeing copied; at least one device management method object used toinitiate, cancel, and reset said computer data management device; and atleast one device management event object used to provide feedback to theClient Module.

In one embodiment, a computer data management device includes at leastone of an electronic image, graphics and document management devicecapable of transmitting at least one of an electronic image, electronicgraphics and electronic document to a plurality of external destinationsincluding one or more of external devices and applications responsivelyconnectable at least one of locally and via the Internet. The computerdata management device comprises one or more of: a first capability tointegrate an image using software so that the image gets seamlesslyreplicated into at least one of other devices and applications, and viathe Internet; a second capability to integrate electronic images intoexisting applications without the need to modify the destinationapplication; an interface comprising a software application that enablescopying images between physical devices, applications, and the Internetusing a single “GO” action; and a third capability of adding at leastone of electronic document and paper processing with a singleprogramming step.

A computer data management device capable of managing and transmittingat least one of an electronic image, electronic graphics and electronicdocument to a plurality of external destinations including one or moreof external devices and applications at least one of locally and via theInternet. The computer data management device includes at least onememory storing at least one of a common and universal interfaceprocedure for communicating and communicating; and at least one dataprocessor responsively connectable to said at least one memory, andimplementing the at least one common and universal interface procedureas a software application for communicating and communicating with theplurality of external destinations including the one or more of theexternal devices and applications.

In one embodiment, a computer readable tangible medium storesinstructions for implementing a process driven by a computer implementedon at least one of an electronic image, graphics and document managementdevice capable of managing and transmitting at least one of anelectronic image, electronic graphics and electronic document to aplurality of external destinations including at least one of an externaldevice and application at least one of locally and via the Internet. Theinstructions control the computer to perform the process of: storing atleast one of a common and universal interface procedure forcommunicating and communicating in at least one memory; and implementingthe at least one of common and universal interface procedurecommunicating and communicating with the plurality of externaldestinations.

In one embodiment, a computer data management device includes at leastone of an electronic image, graphics and document management devicecapable of transmitting at least one of an electronic image, electronicgraphics and electronic document to a plurality of external destinationsincluding one or more of external devices and applications responsivelyconnectable at least one of locally and via the Internet. The computerdata management device includes one or more of: a single function copyaction linking devices, applications and the Internet including at leastone a go action, a single function paper copy between devices andsoftware applications, and a single function paper copy between softwareapplications and devices; a one step programming method to add papersupport to electronic business processes including at least one of a onestep method of supporting paper within electronic business processapplication optionally including legacy devices with no or minimalreprogramming of the electronic business process application, a methodof recreating a module oriented copier in software; and a copierinterface implemented as software application including at least one ofa virtual copier interface method of presenting to a user an action ofat least one of copying files and electronic images, at least one of toand from, at least one of digital imaging devices and softwareapplications, in a substantially single step, and presenting users withdirect access to at least one of tutorial and options from a mainapplication window.

In one embodiment, a server module includes one or more of: enablevirtual copy action means for initiating, canceling, and resetting saidcomputer data management device; maintain list of available module meansfor maintaining a registry containing a list of said input, output, andprocess modules that can be used in said computer data managementdevice, said list being read on startup, and maintaining another copy ofsaid list in a modules object accessible by said input, output, client,process and server modules; maintain currently active modules means formaintaining said input, output, and process modules currently being usedfor a current computer data management device copy action in a programobject, and saving the currently active modules in a process templatefile; and maintain complete document information means for maintaininginformation regarding a current file being copied, and saving theinformation in a document template file.

In one embodiment, a computer data management method includes at leastone of an electronic image, graphics and document management devicecapable of transmitting at least one of an electronic image, electronicgraphics and electronic document to a plurality of external destinationsincluding one or more of external devices and applications responsivelyconnectable at least one of locally and via the Internet. The methodcomprises one or more of the steps of integrating an image usingsoftware so that the image gets seamlessly replicated into at least oneof other devices and applications, and via the Internet; integratingelectronic images into existing applications without the need to modifythe destination application; communicating via a software applicationenabling copying images between physical devices, applications, and theInternet using a single “GO” action; and adding at least one ofelectronic document and paper processing with a single programming step.

In one embodiment, a server method includes one or more of: initiating,canceling, and resetting said computer data management device;maintaining a registry containing a list of said input, output, andprocess modules that can be used in said computer data managementdevice, said list being read on startup, and maintaining another copy ofsaid list in a modules object accessible by said input, output, client,process and server modules; maintaining said input, output, and processmodules currently being used for a current computer data managementdevice copy action in a program object, and saving the currently activemodules in a process template file; and maintaining informationregarding a current file being copied, and saving the information in adocument template file.

A computer data management method includes at least one of an electronicimage, graphics and document management method capable of transmittingat least one of an electronic image, electronic graphics and electronicdocument to a plurality of external destinations including one or moreof external devices and applications. The computer data managementmethod is connectable at least one of locally and via the Internet, andaccesses at least one memory storing a plurality of interface protocolsfor interfacing and communicating, and at least one processorresponsively connectable to the at least one memory. The processorimplements at least one interface protocol as a software application forinterfacing and communicating with the plurality of externaldestinations including the one or more of the external devices andapplications.

In one embodiment, the external devices and applications include, forexample, a printer, a facsimile, and a scanner. In one embodiment, thecomputer data management method includes the capability to integrate animage using software so that the image gets seamlessly replicated andtransmitted to at least one of other devices and applications, and viathe Internet. In one embodiment, the computer data management methodincludes the capability to integrate the electronic images into adestination application without the need to modify the destinationapplication.

In one embodiment, the computer data management method includes anoptional interface that enables copying images between physical devices,applications, and the Internet using a single “GO” operation. In oneembodiment, the computer data management method includes the optionalcapability of adding at least one of electronic document and paperprocessing with a single programming step.

In one embodiment, the software application includes one or more of:managing data comprising at least one of paper and electronic paperinput to the computer data management method, and managing at least oneimaging device to input the data through at least one of a scanner and adigital copier, and managing the electronic paper from at least onethird-party software applications; managing the data output from thecomputer data management method, managing at least one imaging device tooutput the data to at least one of a standard Windows printer, an imageprinter, and a digital copier, and managing the output of the data tothe third-party software application; applying at least one dataprocessing to the data comprising the at least one of the paper and theelectronic paper as it is being copied, applying additionalfunctionality including at least one of workflow and processingfunctionality to the data comprising the at least one of paper andelectronic paper as it is being copied, and applying multiple processesto a single virtual copy; presenting the data comprising the at leastone of paper and electronic paper as it is being copied, and informationrelated to at least one of the input and output functions; andcommunicable with said at least one input, output, client, and processmodules and external applications, and capable of dynamically combiningthe external applications with at least one of digital capturing devicesand digital imaging devices.

In one embodiment, one or more of the external devices and applicationsintegrates the computer data management method into an externalapplication via at least one of running the computer data managementmethod, as an external service and embedding the computer datamanagement method as an embedded service.

In one embodiment, the server module includes one or more of: enablevirtual copy operation means for initiating, canceling, and resettingsaid computer data management method; maintain list of available modulemeans for maintaining a registry containing a list of said input,output, and process modules that can be used in said computer datamanagement method, said list being read on startup, and maintaininganother copy of said list in a modules object accessible by said input,output, client, process and server modules; maintain currently activemodules means for maintaining said input, output, and process modulescurrently being used for a current computer data management method copyoperation in a program object, and saving the currently active modulesin a process template file; and maintain complete document informationmeans for maintaining information regarding a current file being copied,and saving the information in a document template file.

In one embodiment, the server module includes at least one server moduleapplication programmer interface (API). In one embodiment, the servermodule application programmer interface (API) comprises one or more ofthe following COM-based interfaces: at least one modules objectmaintaining a first list of available input, output, and processmodules; at least one program object maintaining a second list ofcurrently selected input, output, and process modules; at least onedocument object maintaining information regarding a current documentbeing copied; at least one method management method object used toinitiate, cancel, and reset said computer data management method; and atleast one method management event object used to provide feedback to theClient Module.

In one embodiment, a computer data management method includes at leastone of an electronic image, graphics and document management methodcapable of transmitting at least one of an electronic image, electronicgraphics and electronic document to a plurality of external destinationsincluding one or more of external devices and applications responsivelyconnectable at least one of locally and via the Internet. The computerdata management method comprises one or more of: a first capability tointegrate an image using software so that the image gets seamlesslyreplicated into at least one of other devices and applications, and viathe Internet; a second capability to integrate electronic images intoexisting applications without the need to modify the destinationapplication; an interface comprising a software application that enablescopying images between physical devices, applications, and the Internetusing a single “GO” operation; and a third capability of adding at leastone of electronic document and paper processing with a singleprogramming step.

A computer data management method capable of managing and transmittingat least one of an electronic image, electronic graphics and electronicdocument to a plurality of external destinations including one or moreof external devices and applications at least one of locally and via theInternet. The computer data management method includes at least onememory storing at least one of a common and universal interface protocolfor interfacing and communicating; and at least one data processorresponsively connectable to said at least one memory, and implementingthe at least one common and universal interface protocol as a softwareapplication for interfacing and communicating with the plurality ofexternal destinations including the one or more of the external devicesand applications.

In one embodiment, a computer readable tangible medium storesinstructions for implementing a process driven by a computer implementedon at least one of an electronic image, graphics and document managementmethod capable of managing and transmitting at least one of anelectronic image, electronic graphics and electronic document to aplurality of external destinations including at least one of an externaldevice and application at least one of locally and via the Internet. Theinstructions control the computer to perform the process of: storing atleast one of a common and universal interface protocol for interfacingand communicating in at least one memory; and implementing the at leastone of common and universal interface protocol interfacing andcommunicating with the plurality of external destinations.

In one embodiment, a computer data management method includes at leastone of an electronic image, graphics and document management methodcapable of transmitting at least one of an electronic image, electronicgraphics and electronic document to a plurality of external destinationsincluding one or more of external devices and applications responsivelyconnectable at least one of locally and via the Internet. The computerdata management method includes one or more of: a single function copyoperation linking devices, applications and the Internet including atleast one a go operation, a single function paper copy between devicesand software applications, and a single function paper copy betweensoftware applications and devices; a one step programming method to addpaper support to electronic business processes including at least one ofa one step method of supporting paper within electronic business processapplication optionally including legacy methods with no or minimalreprogramming of the electronic business process application, a methodof recreating a module oriented copier in software; and a copierinterface implemented as software application including at least one ofa virtual copier interface method of presenting to a user an operationof at least one of copying files and electronic images, at least one ofto and from, at least one of digital imaging devices and softwareapplications, in a substantially single step, and presenting users withdirect access to at least one of tutorial and options from a mainapplication window.

In one embodiment, a server module includes one or more of: enablevirtual copy operation means for initiating, canceling, and resettingsaid computer data management method; maintain list of available modulemeans for maintaining a registry containing a list of said input,output, and process modules that can be used in said computer datamanagement method, said list being read on startup, and maintaininganother copy of said list in a modules object accessible by said input,output, client, process and server modules; maintain currently activemodules means for maintaining said input, output, and process modulescurrently being used for a current computer data management method copyoperation in a program object, and saving the currently active modulesin a process template file; and maintain complete document informationmeans for maintaining information regarding a current file being copied,and saving the information in a document template file.

In one embodiment, a computer data management method includes at leastone of an electronic image, graphics and document management methodcapable of transmitting at least one of an electronic image, electronicgraphics and electronic document to a plurality of external destinationsincluding one or more of external devices and applications responsivelyconnectable at least one of locally and via the Internet. The methodcomprises one or more of the steps of integrating an image usingsoftware so that the image gets seamlessly replicated into at least oneof other devices and applications, and via the Internet; integratingelectronic images into existing applications without the need to modifythe destination application; interfacing via a software applicationenabling copying images between physical devices, applications, and theInternet using a single “GO” operation; and adding at least one ofelectronic document and paper processing with a single programming step.

In one embodiment, a server method includes one or more of: initiating,canceling, and resetting said computer data management method;maintaining a registry containing a list of said input, output, andprocess modules that can be used in said computer data managementmethod, said list being read on startup, and maintaining another copy ofsaid list in a modules object accessible by said input, output, client,process and server modules; maintaining said input, output, and processmodules currently being used for a current computer data managementmethod copy operation in a program object, and saving the currentlyactive modules in a process template file; and maintaining informationregarding a current file being copied, and saving the information in adocument template file.

In accordance with another embodiment of the invention, a computerreadable tangible medium is provided that stores an object thereon, forexecution by the computer.

There has thus been outlined, rather broadly, the more importantfeatures of the invention in order that the detailed description thereofthat follows may be better understood, and in order that the presentcontribution to the art may be better appreciated. There are, of course,additional features of the invention that will be described hereinafterand which will form the subject matter of the claims appended hereto.

In this respect, before explaining at least one embodiment of theinvention in detail, it is to be understood that the invention is notlimited in its application to the details of construction and to thearrangements of the components set forth in the following description orillustrated in the drawings. The invention is capable of otherembodiments and of being practiced and carried out in various ways.Also, it is to be understood that the phraseology and terminologyemployed herein are for the purpose of description and should not beregarded as limiting.

As such, those skilled in the art will appreciate that the conception,upon which this disclosure is based, may readily be utilized as a basisfor the designing of other structures, methods and systems for carryingout the several purposes of the present invention. It is important,therefore, that the claims be regarded as including such equivalentconstructions insofar as they do not depart from the spirit and scope ofthe present invention.

Further, the purpose of the foregoing abstract is to enable the U.S.Patent and Trademark Office and the public generally, and especially thescientists, engineers and practitioners in the art who are not familiarwith patent or legal terms or phraseology, to determine quickly from acursory inspection the nature and essence of the technical disclosure ofthe application. The abstract is neither intended to define theinvention of the application, which is measured by the claims, nor is itintended to be limiting as to the scope of the invention in any way.

These together with other objects of the invention, along with thevarious features of novelty which characterize the invention, arepointed out with particularity in the claims annexed to and forming apart of this disclosure. For a better understanding of the invention,its operating advantages and the specific objects attained by its uses,reference should be made to the accompanying drawings and descriptivematter in which there is illustrated preferred embodiments of theinvention.

These together with other objects and advantages which will besubsequently apparent, reside in the details of construction andoperation as more fully herein described and claimed, with referencebeing had to the accompanying drawings forming a part hereof whereinlike numerals refer to like elements throughout.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is an illustration of the placement and/or use of the computerarchitecture and/or method of the present invention;

FIG. 2 is an illustration of the component factory migrating theoriginal “C”-level API from its original state into the genericinterface defined by the topmost layer;

FIG. 3 is an overview of the computer architecture in the presentinvention;

FIG. 4 is an illustration of the design of an Object in accordance withthe computer architecture of the present invention;

FIG. 5 is an illustration of the architecture comprised of two majorparts;

FIG. 6 is an illustration of the architecture of an engine componentincluding, for example, three layers designed to migrate the originalAPI of the engine to a consistent COM interface;

FIG. 7 is a table illustrating the engine management specification withdefinitions;

FIG. 8 is an illustration of the engine management layer being dividedinto three functions/specifications;

FIG. 9 is an illustration of exemplary tables used to drive the threefunctions of the engine management layer illustrated in FIG. 8;

FIG. 10 is an exemplary table illustrating the engine configurationspecification with definitions;

FIG. 11 is another exemplary table illustrating the engine configurationspecification;

FIG. 12 is an exemplary table illustrating the engine functionalityspecification with definitions;

FIG. 13 is another exemplary table illustrating the engine functionalityspecification;

FIG. 14 is an illustration of a main central processing unit forimplementing the computer processing in accordance with a computerimplemented embodiment of the present invention;

FIG. 15 illustrates a block diagram of the internal hardware of thecomputer of FIG. 14;

FIG. 16 is a block diagram of the internal hardware of the computer ofFIG. 15 in accordance with a second embodiment;

FIG. 17 is an illustration of an exemplary memory medium which can beused with disk drives illustrated in FIGS. 14-16;

FIG. 18 is an illustration of another embodiment of the componentfactory migrating the original “C”-level API from its original stateinto the generic interface defined by the topmost layer;

FIG. 19 is an illustration of a distributed environment or architecturefor manually and/or automatically generating and/or using reusablesoftware components for client server and/or intranet operatingenvironments;

FIG. 20 is a detailed illustration of the distributed environment orarchitecture for manually and/or automatically generating and/or usingreusable software components for client server and/or intranet operatingenvironments;

FIG. 21 is an illustration of a distributed environment or architecturefor manually and/or automatically generating and/or using reusablesoftware components for network environments, such as the Internet;

FIG. 22 is a detailed illustration of the distributed environment orarchitecture for manually and/or automatically generating and/or usingreusable software components in the Internet environment;

FIGS. 23A-23C are illustrations of the image viewer user interfaceand/or functionality associated therewith in accordance with the presentinvention;

FIG. 24 is an illustration of a stand-alone and/or distributedenvironment or architecture for image viewer in client server and/orintranet operating environments;

FIG. 25 is a detailed illustration of a stand-alone and/or distributedenvironment or architecture for image viewer in client server and/orintranet operating environments;

FIG. 26 is an illustration of a stand-alone and/or distributedenvironment or architecture for image viewer in network environments,such as the Internet;

FIG. 27 is a detailed illustration of a stand-alone and/or distributedenvironment or architecture for image viewer in the Internetenvironment;

FIGS. 28 and 29 are illustrations of the interface of the Virtual Copier(VC) embodiment of the present invention with a Go button much like aphysical copier;

FIG. 30 is an illustration of the sequence used with Virtual Copier withjust the Power VC portion of the main Virtual Copier window;

FIG. 31 is an illustration of the five core modules of VC;

FIG. 32 is an illustration of VC recognizing that the third-partyapplication is running, and intelligently copying paper to and from thatapplication;

FIG. 33 is an illustration of a button that can be placed on athird-party application that launches VC in the background;

FIG. 34 is an illustration of the VC logic flow;

FIG. 35 is an illustration of VC updating its Client Module as well asthe results of each Module acting on the document;

FIG. 36 is an illustration of the structure of the Modules Object;

FIG. 37 is an illustration of the structure of the Program Object;

FIG. 38 is an illustration of the internal VDocument mapping to physicalfiles;

FIG. 39 is an illustration of the VDocument Object;

FIGS. 40 and 41 are illustrations of two events that the Server Modulesupports: Error and Status, the Error event being generated anytime anyof the Modules produce an error condition, and the Status event beinggenerated when information needs to be transferred between the IOP orServer Modules and the Client Module;

FIG. 42 is an illustration of a general workflow of the events that aregenerated that manage the flow of modules and user interaction with theServer Module;

FIG. 43 is an illustration of the general logic flow of the ClientModule;

FIG. 44 is an illustration of the basic Client architecture;

FIG. 45 is an illustration of the API for the Input, Process, and OutputModules that are made simple so that third-party vendors can createtheir own custom versions of these modules with relative ease;

FIGS. 46-47 are illustrations of the Feedback object used to communicatebetween the IOP and the Server Module; and

FIG. 48 is an illustration of the basic IOP architecture.

NOTATIONS AND NOMENCLATURE

The detailed descriptions which follow may be presented in terms ofprogram procedures executed on a computer or network of computers. Theseprocedural descriptions and representations are the means used by thoseskilled in the art to most effectively convey the substance of theirwork to others skilled in the art.

A procedure is here, and generally, conceived to be a self-consistentsequence of steps leading to a desired result. These steps are thoserequiring physical manipulations of physical quantities. Usually, thoughnot necessarily, these quantities take the form of electrical ormagnetic signals capable of being stored, transferred, combined,compared and otherwise manipulated. It proves convenient at times,principally for reasons of common usage, to refer to these signals asbits, values, elements, symbols, characters, terms, numbers, or thelike. It should be noted, however, that all of these and similar termsare to be associated with the appropriate physical quantities and aremerely convenient labels applied to these quantities.

Further, the manipulations performed are often referred to in terms,such as adding or comparing, which are commonly associated with mentaloperations performed by a human operator. No such capability of a humanoperator is necessary, or desirable in most cases, in any of theoperations described herein which form part of the present invention;the operations are machine operations. Of course, one or more of theabove operations may alternatively be done manually. Useful machines forperforming the operation of the present invention include generalpurpose digital computers or similar devices.

The present invention also relates to apparatus for performing theseoperations. This apparatus may be specially constructed for the requiredpurpose or it may comprise a general purpose computer as selectivelyactivated or reconfigured by a computer program stored in the computer.The procedures presented herein are not inherently related to aparticular computer or other apparatus. Various general purpose machinesmay be used with programs written in accordance with the teachingsherein, or it may prove more convenient to construct more specializedapparatus to perform the required method steps. The required structurefor a variety of these machines will appear from the description given.

BEST MODE FOR CARRYING OUT THE INVENTION

Reference now will be made in detail to the presently preferredembodiments of the invention. Such embodiments are provided by way ofexplanation of the invention, which is not intended to be limitedthereto. In fact, those of ordinary skill in the art may appreciate uponreading the present specification and viewing the present drawings thatvarious modifications and variations can be made. For example, featuresillustrated or described as part of one embodiment can be used on otherembodiments to yield a still further embodiment. Additionally, certainfeatures may be interchanged with similar devices or features notmentioned yet which perform the same or similar functions. It istherefore intended that such modifications and variations are includedwithin the totality of the present invention.

The purpose of the Virtual Copier (“VC”) aspect of the present inventionis to enable a typical PC user to add electronic paper processing totheir existing business process. VC is an extension of the concept weunderstand as copying. In its simplest form it extends the notion ofcopying from a process that involves paper going through a conventionalcopier device, to a process that involves paper being scanned from adevice at one location and copied to a device at another location. Inits more sophisticated form, VC can copy paper from a device at onelocation directly into a business application residing on a network oron the Internet, or visa versa. The VC invention is software thatmanages paper so that it can be electronically and seamlessly copied inand out of devices and business applications (such as Microsoft Office,Microsoft Exchange, Lotus Notes) with an optional single-step Gooperation. The VC software can reside on a PC, LAN/WAN server, digitaldevice (such as a digital copier), or on a web server to be accessedover the Internet.

Virtual Copier is designed to solve the corporate paper problem byenabling existing web-based and client-server applications to managepaper as part of their solution. Virtual Copier links the familiar anduniversal world of paper and digital devices to web-based andclient-server applications. The result is that the automated businessprocesses become the primary storage of paper in electronic form.Information that is typically managed and processed in paper form is“copied” into the system and managed by the business processes withwhich users are accustomed, which is made possible by using VirtualCopier. Simple extensions of Virtual Copier support seamless electronicoutsourcing of paper processing and archival services over the web.

Virtual Copier is a unique combination of an intuitive application builton an open component architecture that delivers a simple innovation:provide paper processing to existing Intranet and client-server businessprocesses without any fuss. Whether it is an office clerk that needs toeasily copy a report from a desktop scanner to the company'sIntranet-networked copier, or an accounting software integrator thatwants to embed paper processing, Virtual Copier offers a simplesolution. To the office clerk Virtual Copier is a document imagingapplication packaged in the familiar setting of an office copier. To theintegrator, the underlying open architecture of Virtual Copier offers asimple integration path for embedding paper processing into itsclient-server or web-based software solution.

Although managing paper manually is one of the great problems facingcorporations, there has been little innovation in enabling those workersto eliminate the need to continuously work with paper manually. Much ofthe problem stems from the complexity of traditional document managementsystems, which require days of training and months to become familiarwith the system in order to be proficient. Virtual Copier was designedto be as simple as a copier to operate, and yet still provide thecomplete capability of integrating paper with existing businessapplications. By simplifying the interface and underlying softwareinfrastructure, VC can manage paper in electronic form as easily as iscurrently done in physical form.

VC extends the notion of a copier, which simply replicates the image ofan original document onto another piece of paper using a single GO orSTART button, to do a similar operation in software so that the imagegets seamlessly replicated into other devices or applications or theInternet.

An example of this is the actual implementation of Virtual Copier as aconsumer product. The interface of the consumer product called VirtualCopier has a Go button much like a physical copier. This GO button cancopy paper, whether physical or electronic, from one device and orapplication to another device and/or application.

What makes Virtual Copier as simple as its physical counterpart in atleast one embodiment is the fact that it replicates the identicalmotions that a user who is making a copy using a physical photocopiergoes through. When a user photocopies a document, he/she selects wherethey want to copy from (i.e. the sheet feeder), where the user wants tocopy to (i.e. 6 copies collated and stapled) and then presses a GObutton to actually carry out the photocopy process. With Virtual Copierthe process feels familiar because the sequence is the same with justthe Power VC portion of the main Virtual Copier window.

The power of Virtual Copier is the fact that the From can be a physicaldevice (e.g. digital copier, fax or scanner) or an application (e.g.Lotus Notes, Microsoft Exchange, the Internet, or an electronic filingsystem). The To can also be a physical device (e.g. a fax, digitalcopier, or printer) or an application (e.g. Lotus Notes, MicrosoftExchange, the Internet, or an electronic filing system). Even thoughpaper is being copied electronically from devices to applications, fromapplications to devices, from devices to devices, or from applicationsto applications, the user simply has one sequence to execute: selectFrom, select To, and then press GO. Virtual Copier will accomplish alltranslations between device and applications automatically andseamlessly.

Another reason that paper is still a major corporate issue is thattraditional document management systems require that a company invest ina whole new system just to store electronic images. Although this is theonly way that document management systems have been designed anddelivered, it is in fact highly inefficient. Most companies alreadymanage information about physical documents in some form of softwareapplications.

For example, accounting systems have long been used to maintaininformation about invoices and bills that arrive into a company fromoutside sources as physical pieces of paper. When an invoice arrives,its information is keyed into the accounting software, where balancesare maintained and accounts payable information is coordinated. Yet theoriginal invoice is stored manually, and every time that a request ismade for a copy of the signed invoice, someone manually retrieves theinvoice from a physical filing cabinet. Accounting systems, like mostbusiness applications, typically have no way of maintaining anelectronic copy of the physical invoice, and adding a documentmanagement system to an accounting system is cumbersome, costly, anddifficult to maintain, and even more difficult to coordinate.

Virtual Copier solves this problem in at least one embodiment by copyingpaper directly into the existing accounting system. Simply adding a Toitem in the Virtual Copier window enables a user to copy paper directlyinto the appropriate accounting record of the existing accountingsystem. This requires no retraining (users who are trained on theaccounting system will still use the accounting system in the same way),requires no document management system (the electronic copy of thedocument is actually being maintained by the accounting system itself),there is no coordination between two systems (Virtual Copier embeds theinvoice with the appropriate accounting record), and it is simple (oneGo button).

What is true with regard to the example above of an accounting system istrue of most other business applications. The power of Virtual Copier isthat it can turn an information system into a document management systemby adding support for electronic paper directly into the existingbusiness application, whether it is a client, server-based, or web-basedsystem.

Virtual Copier enables corporations to perform sophisticated documentimaging with their existing Web-based and client-server applicationsthrough a user interface that is as familiar as the office copier.Virtual Copier can be used out-of-the-box as a standalone application tocopy, scan, fax, or print images using existing digital devices withincorporate environments or across the web. With the extensions, asdescribed below, Virtual Copier can be integrated into Web-based andclient server applications, such as ERP or accounting systems, toeliminate paper from existing business processes and legacyapplications. Virtual Copier can also be used to support seamless accessto document image processing and archival over the web since, in atleast one embodiment, the VC interface is implemented as a softwareapplication.

VC is architected as an application that delivers end-user functionalitywhile remaining open to third-parties extensions. For example, VC can beviewed as a copier. Like a copier, VC takes paper in, and produces papergoing out. The only difference is that VC does not distinguish betweenelectronic and physical paper.

To accommodate third-party extensions, VC is divided into five essentialmodules. Each module is a counterpart to an aspect that is found on aconventional copier. Based on the modular design of VC, each aspect ofVC can be independently extended, offering much greater flexibility thanconventional copiers.

The five core modules of VC illustrated in are:

Input Module—The Input Module manages paper or electronic paper enteringVC. This module manages imaging devices to input paper through scanners,MFPs, or the new breed of digital copiers. The Input Module also managesreading electronic paper from third-party or proprietary applications.The counterpart to VC's Input Module on a conventional copier is thescanner subsystem.

Output Module—The Output Module manages paper or electronic paperexiting VC. Like the Input Module, this module manages imaging devicesto output paper to standard Windows printers, specialty image printers,MFPs, or the new breed of digital copiers. The Output Module alsomanages writing electronic paper to third-party or proprietaryapplications. The counterpart to VC's Output Module on a conventionalcopier is the printer or fax subsystem.

Process Module—The Process Module applies processing to the electronicpaper as it is being copied. Examples of a process are OCR and ICR. TheProcess Module can also apply non-imaging functionality as well, such asworkflow or other relevant tie-ins to the electronic paper as it isbeing copied. One of the advantages of VC over conventional copiers isthat multiple processes can be applied to a single virtual copy. Thecounterpart to VC's Process Module on a conventional copier is thecontroller.

Client Module—The Client Module presents the electronic paper as it isbeing copied, and any relevant information related to the input oroutput functions. For example, if the Output Module is directed to aprinter, then the Client Module might present the finishingcapabilities; if the Output Module is directed to Goldmine, then theClient Module might present the target contact record to which thedocument is being copied. The counterpart to VC's Client Module on aconventional copier is the panel.

Server Module—Unlike conventional copiers, VC's Server Module is aunique subsystem that can communicate with the other modules as well asthird-party applications. The Server Module is what makes VC a far morepowerful concept than simply an application that can control a scannerand a printer to mimic a copier. The Server Module can be used tocombine third-party applications with the new breed of digital imagingdevices to create unique and custom virtual copier solutions. A virtualcopier can be created with VC by combining a scanner with a printer; orby combining a scanner with an application; or by combing an applicationwith an image printer. In each case VC is dynamically creating a customvirtual copier, with a complete understanding of how paper flows fromthe source to its destination. There is no counterpart to VC's ServerModule on a conventional copier.

One of the primary design goals of VC is to make it simple to integrateVC with third-party applications. There are two options to integratingVC into a third-party application: running VC as an external service, orembedding VC as an underlying service.

VC is in one embodiment and optionally a standalone application thatenables a user to scan (copy) paper from a device to a third-partyapplication, and to print (copy) the reference of an image document froma third-party application to a printing device. VC does not require thethird-party application to be aware that VC is operating. Rather, VCrecognizes that the third-party application is running, and itintelligently copies paper to and from that application.

In this scenario the user is interacting with VC's Client Module inorder to execute a copy operation to and from the third-partyapplication. There does not have to be any changes made to thethird-party application, not even to its interface, in order for VC tooperate. The user of VC only knows that to copy to and from thethird-party application, a custom Input and Output Module must beselected, and the Go button is pressed.

In order to support copying to and from a third-party application, VCmust be able to support extensions that understand each third-partyapplication. This is accomplished through the Input and Output Modules.The Client, Server, and even Process Modules remain independent acrossthird-party applications. However, in order to support outputting to athird-party application, an Output Module is developed that is unique tothat third-party application. Likewise, an Input Module is developedthat is unique to a third-party application in order to support readingimages from that application.

It is the optional Input and Output Modules that render VC extendable.For each third-party application there is a unique pair of Input andOutput Modules that understand the third-party application, and how tocopy images to and from that application. Each Input and Output Moduleregisters itself to the Windows registry so that the Server Module knowshow to find them. In this way Virtual Copier can grow indefinitely, tosupport any number of third-party applications.

The significant point is that the Input and Output Modules have theirown interface, and can be developed independently from any other module.As long as the Input and Output Module conform to the API specified inthis document it will plug-and-play with VC. VC will be able to mix andmatch the custom Input and Output Module with its standard and othercustom Input and Output Modules.

A third-party application can also use the services of VC without itsuser interface. That is, a third-party application can embed VC'sfunctionality and provide its own interface to its functionality. Forexample, rather than have VC as a separate application, a special buttoncan be placed on a third-party application that launches VC in thebackground.

VC is designed so that the Server Module can run independently from theClient Module. All the core functionality, including communicating withthe Input, Output, and Process Modules, are performed directly by theServer Module. The Client Module is generally simply an interface to theServer Module. Therefore, all the services of the Server Module can bemade available in the background to a third-party application withoutthe need for an interface. The third-party application can in factbecome the user's interface to VC.

In order to support VC operating in the background a third-partyapplication merely has to communicate with the Server Module directly,as described later in this document. The Server Module, as all modulesin VC, support COM-based interfaces for simple and direct support fromall major Windows development environments.

The purpose of the computer architecture and process described herein isto create a component factory that can automatically generate reusablesoftware components from sophisticated core software technologies. Many,if not most, core software technologies, such as OCR (Optical CharacterRecognition) or barcode recognition, are designed and implemented usinga “C”-language API (Application Program Interface). The technology isoften complex, requiring months of trial-and-error to correctly developapplication systems using the technology. While there are millions ofIntranet developers and power-PC users who are capable of assemblingcomponent-based systems, I have determined that there are relatively few“C” programmers (estimated at less than 100,000) who can learn andimplement application software with these complex_C′-level API's. It istherefore desirable to develop software tools for automaticallygenerating reusable software components from core software technologiesthus making these software technologies available to a much larger userbase.

Since I have determined that there is no structure or format forimplementing “C”-level API's, the ability to automatically transform aunique API into a standard component would seem impossible since thatwould take a nearly-human level of intelligence. To date, the only way,I am aware, to create a component out of an existing API is to have anexisting programmer in the field do the work for each API. Humans canintelligently analyze an API and create a component based on intelligentdecisions tempered by experience. The challenge of creating a componentfactory is the challenge of partially or substantially recreating thecomponent design and formulating effective implementation decisions.

One would expect the translating a “C”-level API from its native stateinto a component would require human-level intelligence. This is mainlybecause “C”-level APIs have virtually no constraints as to how they canbe implemented. This means that there are an infinity variations ofAPIs, which can only be managed by human-level intelligence. While thispoint is true, I have determined that the appropriate solution starts atthe other side of the equation, which is the component itself.

My solution starts out with a definition of a component that can sustainthe feature/function requirements of any API. In other words, theinterface of a generic component can be defined such that the featuresand functions of virtually any API can be re-implemented within itsbounds. The two known end-points are the “C”-level API that startedwith, and the component interface that represents any set offeatures/functions on the other side.

I have also determined that one solution for creating a computerarchitecture and process for implementing a component factory is tocreate a well-defined multi-tiered systems architecture for a componentand to automate, substantially automate, or manually expedite from itsnative state through the various tiers of the systems architectureresulting in a standardized or substantially standardized component.Advantageously, this solution is not based on making human-levelintelligent decisions on how to translate a_C′-level API into acomponent. Rather, by starting with a well-defined systems architecturethat is multi-tiered, a series of incremental steps that migrates aC-level API from one tier within the systems architecture to the nextmay be performed, and which are facilitated using the architectureand/or process described herein.

Advantageously, each incremental step is not a major one, but insequence the entire series of steps will result in a usable component.Since each step of migration is not a major one, the chances ofautomating these steps is significantly higher and the likelihood ofbeing able to create the component factory becomes more feasible.

The fundamental building blocks of the computer architecture and processare twofold:

-   1) To define a systems architecture that describes in detail how to    implement a component from a C-level API-   2) To create a component factory by automating, substantially    automating, or manually expediting the migration of a C-level API    from one tier within the architecture to the next.    The building blocks are the keys or important to actually making the    component factory feasible.

Significantly, the computer architecture and processes described hereinhave application to the Intranet and document market marketplace.Corporations are embracing internet computing technologies to createenterprise-level Intranets and Extranets. Using standard browsertechnologies, corporations and government entities are rapidly adoptingthe internet computing model and are developing enterprise applicationsby assembling standard Microsoft specified Active X components. Theseare not “C” programmers; rather they are typical power PC users. Furtheravailability of reusable components would only fuel this development.

The general outline for creating a component factory is described belowin detail. It is important to note that automatically, substantiallyautomatically, or manually building a component is neither obvious norguaranteed. As will be described below in detail, automating orsubstantially automating the building of a component consists ofautomating individual steps that comprise the component architecture.However, in today's application environment, any amount of automationwill dramatically increase the efficiencies of building a component

The computer architecture is designed for managing a diverse set ofindependent core technologies (“engines”) using a single consistentframework. The architecture balances two seemingly opposingrequirements: the need to provide a single consistent interface to manydifferent engines with the ability to access the unique features of eachengine.

The benefit of the architecture is that it enables a company to rapidly“wrap” a sophisticated technology so that other high-level developerscan easily learn and implement the core technology. The computerarchitecture is therefore a middleware or enabling technology, asillustrated in FIG. 1.

As illustrated in FIG. 1, computer architecture 2, described below indetail, is a middle layer between high level developer programs 4 (suchas C-level APIs, or other programs having similar characteristics) andare technology/component engines 6 (such as OCR, bar code recognition,and other components having similar characteristics).

Another benefit of the architecture is that it provides a high-levelspecification for a consistent interface to any core technology. Once ahigh-level developer learns the interface described herein for oneengine, that knowledge is easily transferable to other engines that areimplemented using the architecture. For example, once a high-leveldeveloper learns to use the computer architecture for OCR (OpticalCharacter Recognition), using the computer architecture for otherengines, such as barcode recognition or forms processing, is trivial.

In summary, the architecture and process described herein is at once aframework for rapidly wrapping sophisticated technologies intohigh-level components, as well as a framework for high-level developersto communicate with a diverse set of engines. The creating of acomponent factory is based on the fact that the architecture defines aclear path for “wrapping” any C-level API into a component using simplestructures and many rote steps. This process is currently being done inan inefficient manner by a programmer in the field.

The method described herein for creating a component factory creates awell-defined multi-tiered architecture for a component and automates,substantially automates, or manually expedites (hereinafter “automates”)the process of migrating a “C”-API from its native state through thevarious tiers of the architecture resulting in a standardized component.

Advantageously, the method described herein does not base the componentfactory on making human-level intelligent decisions on how to translatea “C”-level API into a component. Rather, by creating a well-definedarchitecture described below that is multi-tiered, the method is aseries of incremental steps that need to be taken to migrate the“C”-level API from one tier within the architecture to the next. In thisway each incremental step is not a major one, but in sequence the entireseries of steps will result in a component.

Since each step of migration is not a major one, the chances forautomating these steps is significantly higher and the likelihood ofbeing able to create the component factory becomes feasible. Thisapproach is in fact what makes the method cost-effective, since thealternative approach, i.e., computer-generated human-level decisionmaking, is currently unavailable and would require much effort, if atall possible, to replace humans in any realistic decision-makingprocess.

With a fixed architecture that can be used to implement a “C”-level APIas a component (using a programmer), that same architecture can be usedas the basis for the component factory model. In order to make thecomponent factory, each step of the architecture needs to be designed tofacilitate automation or manually expedited. In other words, I havedetermined that automating/expediting the process of taking the original“C”-level API and migrating it to a Level 1 layer, and then a Level 1 toa Level 2, and then a Level 2 to a Level 3 layer, and so on, thecomponent has been implemented automatically, or more efficientlymanually. The component factory is therefore a sum of the ability toautomate migrating the “C”-level API from one layer to the next within awell-defined architecture for implementing components.

As illustrated in FIG. 2, the component factory 10 migrates the original“C”-level API 12 from its original state into the generic interface 8defined by the topmost layer. The first feature that can be demonstratedis that there is a topmost layer 8 that can define a component interfacethat can represent the features/functions of most core technologies. Thecomponent factory 10 migrates the “C”-level API 12 to the topmost level8. Doing this in one large step would be impossible since the “C”-levelAPI has a near-infinite variety of styles. However, the architectureadvantageously has enough well-defined and well-structured layers forimplementing the topmost component interface, for creating the componentfactory.

A simplified overview of the architecture is illustrated in FIG. 3. InFIG. 3, the component interface 8 sits on top of an Object Manager 14that communicates with individual objects e.g., 16, 18, 20. Theseobjects 16, 18, 20 represent specific core technologies that arerepresented as “C”-level APIs. The design of Object1, Object2, . . .ObjectN is illustrated in FIG. 4.

A component factory can be created by automating the process ofmigrating the original “C”-level API 12 from its original state to theLayer 1—Engine Management tier 26, and then from the state to Layer 2Engine configuration tier 24, and so on up the Engine Functions layer22. These layers will be further described below.

The computer architecture is implemented, for example, as a standard COMcomponent, as an ActiveX control; the specifications designed byMicrosoft, published in the technical literature, and incorporatedherein by reference. ActiveX control (COM) support is currentlyavailable within any Microsoft 32-bit Windows operating environment.ActiveX controls are supported by all OLE-based applications, includingall of Microsoft's end-user products (e.g., Microsoft Office, Word,Access, Powerpoint, Access), the main Internet Browsers (Microsoft'sInternet Explorer and Netscape's Navigator—the latter with an add-inproduct and by 4Q97 directly), most other name-brand end-user Windowsproducts (e.g., Lotus Notes), and all major development environments(e.g., Microsoft Visual Basic and Visual C++, Delphi, Borland C++, PowerBuilder). By implementing the architecture as, for example, an ActiveXcontrol, complex technologies can be programmed by virtually any Windowsor Intranet user or developer. Of course, other component specificationsmay also be used.

Although the architecture has been implemented as a COM-based technologywith C++ as the language of choice, the architecture can be implementedin many other languages (e.g. Java) and distributed architectures (e.g.CORBA).

Every engine, such as a text retrieval or an OCR (Optical CharacterRecognition) engine, has a unique interface. This interface is generallya “C”-level API (Application Program Interface). In most cases, thelearning curve for understanding and integrating a new engine can be aone man-month to several man-years and generally requires highlyexperienced “C” programmers. The purpose of the architecture is todefine a clear infrastructure within which any core can be rapidly“wrapped” so that users and developers can have easy access to thesecore technologies.

In addition to defining the infrastructure for engines to be accessibleto typical users, the architecture also defines how to migrate an enginefrom its native state to the prescribed interface. In other words, thearchitecture goes beyond simply defining the framework for wrappingengines, it also defines the specific steps for wrapping these engines.

The architecture consists of a hierarchical series of layers that takeany “C”-level API from its unique state to one that is standard andconsistent. The result is a single, highly-integrated object componentthat contains and manages any type of engine that can be programmedregardless of the nature and subject of the core technology. Thearchitecture therefore not only defines the goal (e.g., the objectcomponent interface) but also the means of implementing that goal forany type of engine.

The architecture is comprised of two major parts as illustrated in FIG.5: the Object Manager 14, and the individual object components 16, 18,20. The Object Manager 14 in FIG. 5 manages individual object components16, 18, 20 illustrated as Object 1, Object 2, etc. The Object Manager 14communicates with the individual object components 16, 18, 20 using aconsistent COM interface.

Each object component implements the feature set of an individual engineby mapping a consistent COM interface to the “C”-Level API interface ofthe individual engine that it supports. In this way the Object Managercan consistently communicate with each engine, using the engine's objectcomponent. Because the COM interface of each object component isconsistent, the Object Manager can interface with every underlyingengine the same way.

The features of the architecture include:

-   1) definition of consistent COM interfaces for individual object    components that represent diverse technologies;-   2) a prescribed process for migrating any engine to the defined    consistent COM interface; and/or-   3) a predefined Object Manager that automatically manages the    individual object components.

When implemented, for example, as an ActiveX control, the architecturealso yields an umbrella control that can be used by a high-levelprogrammer to program and manage numerous sophisticated technologies ina plug-and-play environment. In order to facilitate the discussion ofthe architecture itself it is best to start with the architecture of theengine object component and then describe the Object Manager. Since theObject Manager is directly dependent on the engine object components, anunderstanding of the latter will assist in the description of theformer.

Engine Object Component—16, 18, 20

The purpose of the engine object is to wrap a specific engine using aseries of layers that convert the engine's unique interface into a COMinterface that is, for example, specified by the architecture. Thearchitecture not only defines the consistent COM interface forimplementing an engine, it also describes how to implement the interfacefrom the original “C”-Level API. Once the COM interface of the engineobject component is implemented, the Object Manager understands and cantherefore communicate with it.

Each engine component consists of, for example, three layers that aredesigned to migrate the original API of the engine to a consistent COMinterface. As illustrated in FIG. 6, the Object Manager 14 communicateswith the topmost layer 22 of the object component 16, 18, 20 which isthe defined interface of object component.

Each layer is described below in two parts. The first part is theprescribed COM interface for communicating with the engine objectcomponent. The second part describes a specific path for automatingbuilding the layer. By providing an outline for automating building eachlayer, the overall engine object component can be automatically,substantially automatically or manually expedited and generated.

Layer 1—Engine Management 26

The first layer in the object component architecture is designed to dealwith the fundamental features of an engine. This includes the ability toload and unload the standard or commercially available via, for example,MicroSoft Corporation, engine Dynamic Link Libraries (DLLs) into memory,as well as the ability to consistently deal with errors. This is themost fundamental layer because it is the essential “wrapper” layer of anengine. Once this layer is complete all interaction with the underlyingengine is filtered through this layer. Additional important enginemanagement functions include dynamically accessing a function call of anengine, and initializing engine settings. All of these engine managementfunctions are optionally and beneficially table driven to promote orfacilitate access to, and implementation of, engine managementfunctions.

The Layer 1 specification is summarized in FIG. 7 that describes theIEngineManagement COM interface. The purpose of the IEngineManagementinterface is to transparently load and unload an engine to and frommemory. I have determined that this is often the core feature that isincorrectly implemented and a cause for hard-to-find bugs. This layermay be generated manually by a developer who is familiar with thearchitecture as outlined herein in an expedited manner or automaticallyas described below in detail.

Layer 1 can be precisely defined in generic terms, and is therefore thesimplest layer to likely be automatically, substantially automatically,or easily manually generated. A sample or example of actual code thatcan be used to implement this layer is described below. As long theprocess and/or code for implementing Layer 1 can be generically defined,that is engine and technology independent, then the process ofgenerating the generic code for each new engine is expedited eithermanually or automatically.

The premise for automating any level is to start with as few pieces ofinformation as possible. For the Engine Management layer I have assumedthat nothing more than the set of DLLs that implement the enginefunctionality are known. Given this information, I have determined thatI will need to implement:

-   -   Loading and unloading the engine from memory    -   Adding error management

We can start, in this example, with a model C++ header file that definesthe Engine Management layer and investigate how this code can beimplemented generically. As mentioned earlier, if the code to implementthis layer can be defined generically then it can be easily generated,for example, manually, and/or automatically for any engine.

class SomeEngineObject {  //Wrapper Functions private: FARPROC_SomeFunction;  BOOL SomeFunction◯;  //EngineManagementprotected:  BOOL GetProcAddress(HINSTANCE,FARPROC&,LPCTSTR);  BOOLGetProcAddresses◯;  BOOL ProcessError◯; public:  BOOLActivateEngine(BOOL Activate);  BOOL IsEngineActivated◯; };

The IEngineManagement interface is implemented in the C++ class as thepublic methods: ActivateEngine◯ and IsEngineActivated◯.

The first step of implementing the Engine Management layer 20 is to wrapeach original engine function within a class-defined function thatrepresents the original. For example, if there is an original functioncalled SomeFunction◯, then the engine object should have a correspondingSomeFunction◯ method. The engine object version can then add standardengine and error management code so that any layers above have automaticerror detection, correction, and reporting.

An example of generic code that maps an original function call to theoriginal function is as follows:

BOOL GetProcAddress(HINSTANCE hLib,FARPROC&Proc, LPCTSTR ProcName) { Proc=::GetProcAddress(hLib,ProcName)  if(!Proc)  {  SetIMAGmEError(LOADENGINEFUNCTIONSERROR, ProcName);   return FALSE;  } return TRUE;

Given the original function name, the GetProcAddress can map theoriginal function to one that is defined by the engine object. Using theengine object C++ header file described above, the SomeFunction◯ methodis mapped to the original engine function using the following line ofcode:

(GetProcAddress(hLib, SomeFunction, “SomeFunction”);

To map all the function calls within the original engine DLLs justrequires cycling through each function call and mapping it to the engineobject counterpart. Since Windows contains facilities that enablesaccess to all the functions within a DLL, a simple loop may be used. ThehLib module is derived from the DLL name, which, as mentioned at thestart, is the one piece of information we are given.

What is more complex is to define a generic implementation of the engineobject version of the original function. This may be described in codeas follows:

 BOOL SomeFunction(arguments)  ASSERT(arguments) ErrorVariable=_SomeFunction(arguments);  returnProcessError◯; }

The engine object version of the original function passes the functioncall to the original one after completing a series of assertion tests,and is followed by a series of error detection tests. In this way theoriginal engine function is “wrapped” by the engine object to manageerror detection and correction.

The process of loading an engine can likewise be implementedgenerically.

BOOLLoadDLLs◯ {  BOOLbReturn=TRUE;  HINSTANCEt_hLib; CStringt_ModuleName;  POSITIONpos;  pos=m_Modules.GetStartPosition◯; if(pos=NULL)  {   SetIMAGinEError(NOMODULESDEFINED);   return FALSE; } while(pos&&bReturn)  {   m_Modules.GetNextAssoc(pos,t ModuleName,thLib);   if(t_hLib!=NULL)    continue;  t_hLib=::LoadLibrary(t_ModuleName);   if(t_hLib=NULL)   {   SetIMAGinEError(CANTLOADMODULE,t_ModuleName);    FreeDLLs◯;   bReturn=FALSE;    break;   }   m_Modules.SetAt(t_ModuleName, t_hLib); } returnbReturn; }

The LoadDLLs function is a generic implementation of a function thatloops through the names of DLLs that are provided (in the form of them_Modules variable), and cycles through each one loading it into memoryusing the Windows LoadLibrary◯ function. A similar engine objectfunction can be implemented to remove these DLLs from memory.

The present invention further divides the engine management layer intothree functions, as illustrated in FIG. 8. The first function is loadingand unloading 124 of the core or engine technology. The second functionfor the engine management layer 26 is dynamically linking procedures orfunction calls, or hooking the desired engine functionality into theprocedures of the core technology 126, including, for example,initializing and setting up engine settings. The third function isinitializing the engine itself 128, which is essentially enginemanagement. Once these three functions are performed in level 1,anything in the core technology is accessible.

Advantageously, the present invention utilizes tables to drive each ofthese three functions described above, and as illustrated in FIG. 9.Each of the tables of files, for example tables 130, 136, 140, arefilled in with the appropriate data or information. I have discoveredthat if the above three functions are set up or implemented usingtables, that the core technology may be effectively and efficientlydescribed. That is, the use of tables is a very effective and simplemethod of describing an engine for use in engine management, engineloading/unloading and engine procedure linking. For example, it issimilar to indicating or providing the raw data of that engine, the listof the engine functions, and the list of the engine dynamic linklibraries (DLLs) for engine management.

The files or tables contain the logic or executable of the engine.Accordingly, all that is needed is a list of the engine functions 132, alist of the file of the engine executable code or DLLs 138, and a listof the engine settings 142. Using the tables with the above information,the engine may be automatically loaded and unloaded, initialized, and/ordynamically hooked into the necessary functions. Accordingly, theprocess of generating level 1 for engine management may advantageouslybe automated. The specific algorithms used for the engine managementlayer are described in the Appendix.

In summary, for the Engine Management layer the following pieces may beautomated, substantially automated, and/or manually expedited.

-   -   Loading and unloading the engine DLLs (provided into and out of        memory    -   Mapping original functions to engine object counterparts    -   Adding general error detection and correction    -   Determining and matching arguments and return values for mapping        the original functions to their engine object counterparts. In        order to add assertion and error detection and correction, the        original function must be wrapped and called from within the        engine object version of the original function.    -   Managing error feedback. All APIs have their own way of        providing error feedback. Since one of the goals of the Engine        Management layer is to generically manage error detection,        correction, and feedback, it must handle all errors identically.        However, APIs have numerous and incompatible methods in this        case. I have determined that most APIs follow one of several        distinct mechanisms for providing error feedback. By creating        specific classes of APIs, the process of generating Layer 1        engine management may be expedited, manually and/or        automatically.

Layer 2—Engine Configuration 24

The second layer 24 in the object component architecture is designed todeal with configuring an engine. This includes the ability to set anyvariety of features that are generally associated with the functioningof an engine. The architecture is designed to meet the challenge ofproviding a uniform interface for dealing with generally any or mostengine settings.

The engine configuration layer 24 includes a series of prefabricatedfunctions that map out the settings stored in the table to theappropriate engine configuration parameters. Accordingly, all that isneeded is to fill in the values for the table associated with engineconfiguration. Thus, the engine object may advantageously comepre-packaged with predetermined tables populated with predeterminedvalues.

The Layer 2 specification can be summarized in FIG. 10 that describes anexemplary IEngineConfiguration COM interface. The purpose of theIEngineConfiguration interface is to provide the ability to set and getthe settings of any engine uniformly. While the Engine Management layercan load and unload engines transparently, this layer configures enginesto operate as required by the user or developer.

FIG. 11 is another exemplary table illustrating the engine configurationspecification. Examples include a set setting function 144, a getsetting function 146, a load setting 148, a save setting 150, an issetting valid function 152, a default setting 154, and a prompt setting156.

The get setting 146 and set setting 144 functions retrieve the value ofa particular engine setting, or assign a value to a particular enginesetting, respectively. Each one of the get setting and set settingfunctions includes or comprises a table of the settings. The loadsetting 148 and save setting 150 functions do the similar function asthe get setting and set setting functions, but in persistence.Persistence is defined as writing values to the disk, for example harddisk, compact disk, and the like, and retrieves the values from thedisk. So as where the get setting and set setting functions assign avalue and/or retrieves the value from local memory, the load and setsetting functions assign the value and retrieve the value of the settingfrom disk. The load and set setting functions provide persistence whenthe computer system is close down, such that when the computer systemwill return to the last setting when it is subsequently reopened.

The default setting function 154 provides the most favorable value for agiven setting. Thus, if no setting is selected, the system willautomatically select default settings. The prompt setting function 156is what displays to the user all the various settings. Advantageously,the present invention generates the skeletal structure of each tableautomatically. In addition, since there is a table of settings, theskeletal structure not only generates these functions, but also fills inthe settings that need to be assigned. Thus, the engine configurationfunction provides the feature of having a pre-populated set of optionswhich require particular values to be assigned to table entries.

Although this architecture advantageously makes it simple for a human tomigrate the configuration of an engine appear into two simple anduniversally applicable interface points, doing so automatically requiresadditional steps. The two steps to automating this approach are, forexample, as follows:

-   -   Determine the configuration methods used by various APIs for        configuring the core technology;    -   Detect the variations for configuring an engine and automating        each one separately.

As with Layer 1—Engine Management, there exists a finite set of generalvariations used by developers of core technologies to configure anengine. Although Layer 1 is clearly more generic in nature,advantageously, Layer 2 also has considerable consistency.

Layer 3—Engine Functionality 22

The third layer 22 in the object component architecture is designed todeal with accessing the actual functionality of the core engine. Forexample, for an OCR engine this would be to OCR an image or a document.For a text retrieval engine this would be to initiate and retrieveresults of a text search.

An exemplary Layer 3 specification can be summarized in FIG. 12 thatdescribes the IEngineFunction COM interface. The purpose of theIEngineFunction interface is to provide the ability to initiate anyfunction supported by an engine. The simple IEngineFunction interface iscapable of managing an infinite variation of functions.

The third layer may advantageously be further divided into manysub-layers that more discretely define the steps necessary to execute afunction within an API. Since the designer of an API has infinitevariety of possible ways of implementing a function, creating a tieredarchitecture to manage this layer is useful.

An exemplary tiered architecture for the engine function is illustratedin FIG. 13. As illustrated in FIG. 13, the engine function or engineprocessing layer includes four elements. The engine function layer 22includes a series of predefined functions to perform in the performelement 158.

For example, for optical character recognition (OCR), the presentinvention uses a set of predefined functions. Alternatively, forscanning, the present invention includes a separate set of predefinedfunctions.

Accordingly, there are a series of actions that are performed by theengine function layer on a given engine, such as an OCR engine, ascanning engine, a printing engine and the like. The engine functionlayer is designed not to generally go directly to a specific engine.Rather, the engine function layer 22 will generally interface with theengine management layer 26 and/or the engine configuration layer 24 asneeded.

For example, in the course of performing an action and/or function, theengine function layer interfaces with the engine configuration layer topossibly modify settings. For an OCR engine, the engine function layerfills out a table of OCR documents as one action that could take place.OCR image is another action.

The get function results 160 gets the results of the function stored ina register. The clear function 162 clears all the registers that containall the results, in this case its memory. The feedback event or function164 provides continuous feedback, depending on what action takes place.For example, if an OCR action is being performed, the feedback functionprovides the percentage of completion of the OCR process.

The automation of this layer is accomplished by the following functions:

-   -   Determine the execution of methods used by various APIs for        executing a given function;    -   Divide this layer into a multi-tiered layer that further        facilitates automation;    -   Detect the variations of the sub-layers and automate each one        separately.

Although this layer has many more variations than Layer 2, I havedetermined that there is a general set of variations used by developersof APIs to implement core functionality.

Thus, the benefit of the component factory is that it can transform coresoftware technologies that are currently available in “C”-level APIs toa limited audience into components that have a much greater audience.

There are a variety of “C”-level APIs that cover the followingcategories of functionality that can be better served in the market asActiveX controls or other component and used in conjunction with thearchitecture and methods described herein.

-   -   Text Retrieval    -   Data Extraction    -   Workflow    -   Storage Management

Each of these categories has several vendors with products thatcurrently service the market in a limited way because the technologiesare only available as “C”-level APIs. Without the core competency ofcreating components out of these core technologies they are limitingtheir marketability and opportunity for international distribution.

With the proposed component factory users and vendors can rapidly createcomponents from their original core technology and increase theirmarketability, competitiveness, and ultimately their sales.

Further, there are numerous core technologies, such as text-retrievaland ICR (Intelligent Character Recognition), that have already beenimplemented, and are only available as “C”-level APIs. Many, if notmost, core technologies are first released exclusively as “C”-levelAPIs. While there are integrators and corporations who have the team oftechnologists who can integrate these “C”-level APIs in-house, mostcompanies are looking for component versions that can be implemented ata much higher level. Therefore, many of the core technologies that areonly available in a “C”-level API are not being used due to theirinaccessible interface. The benefit of the component factory is that itcan rapidly make available core technologies implemented as “C” APIsthat would otherwise be underutilized or dormant in research labs byconverting them to high-level components that can be used by millions ofpower-PC users.

With the advent of the World Wide Web (WEB) this opportunity hasincreased exponentially. The WEB is now home to a vast number of WEBauthors with minimal formal training who can implement HTML pages andbuild web sites. One of the fundamental technologies for extending thecapability of the WEB from simple page viewing to interactive andsophisticated applications is components. A component extends thecapability of HTML by enabling a WEB author to add core technology as apre-packaged technology. Since components are fundamental to the growthand usability of the WEB, having a component factor that can translate“C”-level toolkits into components that are then usable within WEB sitesopens a vast and new worldwide market to these technologies.

FIG. 14 is an illustration of a main central processing unit forimplementing the computer processing in accordance with a computerimplemented embodiment of the present invention. The proceduresdescribed above may be presented in terms of program procedures executedon, for example, a computer or network of computers.

Viewed externally in FIG. 14, a computer system designated by referencenumeral 40 has a central processing unit 42 having disk drives 44 and46. Disk drive indications 44 and 46 are merely symbolic of a number ofdisk drives which might be accommodated by the computer system.Typically these would include a floppy disk drive such as 44, a harddisk drive (not shown externally) and a CD ROM indicated by slot 46. Thenumber and type of drives varies, typically with different computerconfigurations. Disk drives 44 and 46 are in fact optional, and forspace considerations, may easily be omitted from the computer systemused in conjunction with the production process/apparatus describedherein.

The computer also has an optional display 48 upon which information isdisplayed. In some situations, a keyboard 50 and a mouse 52 may beprovided as input devices to interface with the central processing unit42. Then again, for enhanced portability, the keyboard 50 may be eithera limited function keyboard or omitted in its entirety. In addition,mouse 52 may be a touch pad control device, or a track ball device, oreven omitted in its entirety as well. In addition, the computer systemalso optionally includes at least one infrared transmitter 76 and/orinfrared receiver 78 for either transmitting and/or receiving infraredsignals, as described below.

FIG. 15 illustrates a block diagram of the internal hardware of thecomputer of FIG. 14. A bus 56 serves as the main information highwayinterconnecting the other components of the computer. CPU 58 is thecentral processing unit of the system, performing calculations and logicoperations required to execute a program. Read only memory (ROM) 60 andrandom access memory (RAM) 62 constitute the main memory of thecomputer. Disk controller 64 interfaces one or more disk drives to thesystem bus 56. These disk drives may be floppy disk drives such as 70,or CD ROM or DVD (digital video disks) drive such as 66, or internal orexternal hard drives 68. As indicated previously, these various diskdrives and disk controllers are optional devices.

A display interface 72 interfaces display 48 and permits informationfrom the bus 56 to be displayed on the display 48. Again as indicated,display 48 is also an optional accessory. For example, display 48 couldbe substituted or omitted. Communication with external devices, forexample, the components of the apparatus described herein, occursutilizing communication port 74. For example, optical fibers and/orelectrical cables and/or conductors and/or optical communication (e.g.,infrared, and the like) and/or wireless communication (e.g., radiofrequency (RF), and the like) can be used as the transport mediumbetween the external devices and communication port 74.

In addition to the standard components of the computer, the computeralso optionally includes at least one of infrared transmitter 76 orinfrared receiver 78. Infrared transmitter 76 is utilized when thecomputer system is used in conjunction with one or more of theprocessing components/stations that transmits/receives data via infraredsignal transmission.

FIG. 16 is a block diagram of the internal hardware of the computer ofFIG. 14 in accordance with a second embodiment. In FIG. 16, instead ofutilizing an infrared transmitter or infrared receiver, the computersystem uses at least one of a low power radio transmitter 80 and/or alow power radio receiver 82. The low power radio transmitter 80transmits the signal for reception by components of the productionprocess, and receives signals from the components via the low powerradio receiver 82. The low power radio transmitter and/or receiver 80,82 are standard devices in industry.

FIG. 17 is an illustration of an exemplary memory medium which can beused with disk drives illustrated in FIGS. 14-16. Typically, memorymedia such as floppy disks, or a CD ROM, or a digital video disk willcontain, for example, a multi-byte locale for a single byte language andthe program information for controlling the computer to enable thecomputer to perform the functions described herein. Alternatively, ROM60 and/or RAM 62 illustrated in FIGS. 15-16 can also be used to storethe program information that is used to instruct the central processingunit 58 to perform the operations associated with the productionprocess.

Although processing system 40 is illustrated having a single processor,a single hard disk drive and a single local memory, processing system 40may suitably be equipped with any multitude or combination of processorsor storage devices. Processing system 40 may, in point of fact, bereplaced by, or combined with, any suitable processing system operativein accordance with the principles of the present invention, includingsophisticated calculators, and hand-held, laptop/notebook, mini,mainframe and super computers, as well as processing system networkcombinations of the same.

Conventional processing system architecture is more fully discussed inComputer Organization and Architecture, by William Stallings, MacMillamPublishing Co. (3rd ed. 1993); conventional processing system networkdesign is more fully discussed in Data Network Design, by Darren L.Spohn, McGraw-Hill, Inc. (1993), and conventional data communications ismore fully discussed in Data Communications Principles, by R. D. Gitlin,J. F. Hayes and S. B. Weinstain, Plenum Press (1992) and in The IrwinHandbook of Telecommunications, by James Harry Green, Irwin ProfessionalPublishing (2nd ed. 1992). Each of the foregoing publications isincorporated herein by reference. Alternatively, the hardwareconfiguration may be arranged according to the multiple instructionmultiple data (MIMD) multiprocessor format for additional computingefficiency. The details of this form of computer architecture aredisclosed in greater detail in, for example, U.S. Pat. No. 5,163,131;Boxer, A., Where Buses Cannot Go, IEEE Spectrum, February 1995, pp.41-45; and Barroso, L. A. et al., RPM: A Rapid Prototyping Engine forMultiprocessor Systems, IEEE Computer February 1995, pp. 26-34, all ofwhich are incorporated herein by reference.

In alternate preferred embodiments, the above-identified processor, andin particular microprocessing circuit 58, may be replaced by or combinedwith any other suitable processing circuits, including programmablelogic devices, such as PALs (programmable array logic) and PLAs(programmable logic arrays). DSPs (digital signal processors), FPGAs(field programmable gate arrays), ASICs (application specific integratedcircuits), VLSIs (very large scale integrated circuits) or the like.

FIG. 18 is an illustration of another embodiment of the componentfactory migrating the original “C”-level API from its original stateinto the generic interface defined by the topmost layer. This powerfularchitecture goal is to supply easy access to all imaging functions thatcan be performed by any engine.

The architecture according to this second embodiment, groups C-leveltoolkits 100 into logical categories, such as scan, print, display, OCR,cleanup and so on. A single engine can span multiple categories (e.g.,Kofax engine does view/print/scan). This enables the architecture todeal with the multitude of engines available in a logical fashion.

On top of these, a three-level C++ class (or object) 102 is built foreach engine. This object gives uniform access to the engine and to allits unique settings. The three levels do the following:

Level 1 of the C++ classes 112 is a protective wrapper for each functioncall in the underlying engine. It traps all errors and provides errormanagement and administration to prevent accidental GPFs or enginecrashes.

Think of it as the “condom layer.” While providing the most directaccess feasible to the underlying engine and all its capabilities, level1 of the C++ class 112 also protects the user from the engine. Itmanages all engine loading and unloading, prevents multiple copies of anengine and calls engines automatically as needed.

The architecture also provides three levels of access: 1. Use thedefault engine settings. Benefit: No learning up front. Program knowingnothing other than “OCR gets text out of there.” 2. Prepackagecustomized engine settings. Set it once for everyone who uses theprogram, every time they use the program. 3. Modify engine settings atrun-time. Let the user choose the settings.

Level 2 of the C++ classes 114 bridges the low-level API calls so theycan be used by level 3 116 in standardized calls for each category. Andit supplements the engine by providing additional functionality, such assafely loading and unloading engines.

Level 3 of the C++ class 116 consists of a standardized set of calls forall engines in each category. Programmers can access all the uniquefunctions of each engine in a uniform way.

Another associated C++ class, called a Visual Class 104, adds a visualinterpretation of each engine. This class manages all user interactionwith each underlying engine. Like their lower-level counterparts, theVisual Class consists of three layers:

Level 1—118 adds any dialogs or other pop-up window capability that maybe lacking in each engine. Examples: Dialogs to customize the enginesettings or, for a recognition engine, the zone definition settings.

Level 2—120 serves two functions: It bridges level 1 dialogs with theactual Windows window that represents the control. It also handles allWindows-related error message presentation.

Level 3—122 manages anything else from the underlying engine (such asannotations) that needs to appear on the window. The Visual Classincludes engine-specific Windows dialog boxes that let you customizewhich engine features you want to use, as well as any other Windowsrepresentation necessary for a toolkit. (For example, a compressionengine has to display the image—the visual class, not the engine, doesthe work.)

The Object Manager layer 106, the first horizontal umbrella,orchestrates the underlying objects. It translates service requests intoa form that the engine objects can understand.

The Windows Manager 108 presents Windows messages (move window,mouse/scrollbar/toolbox activity) to the Object Manager. It is writtenusing Microsoft's Foundation Class (MFC), which makes it easy to supportOCXs. (The OCX is in fact an MFC class.)

At the top, a visual interface 110 presents to the user a set of visualcalls and translates those calls into Windows messages. This layercomprises only 5% of the VBX code, yet it permits the toolkit to appearas a VBX, OCX or other standard visual interface.

Accordingly, the present invention provides two main layers, the engineobject component layer and the object manager layer. By creating thesetwo main layers, the present invention allows third parties to createtheir own engine object component layers so that the third party enginecan be readily compatible and useable by the present invention. Inaddition, the present invention is accessible via the Internet. That is,the present invention is operable over the Internet using, for example,standard Internet protocols, such as component object module (COM)communication protocol and distributed COM (DCOM) protocol.

In addition, the present invention optionally combines three layers offunctions including the visual interface, the windows manager and theobject manager into one layer called the object manager. Of course, thiscombination of layers is not meant to convey that only these specificlayers must be used, but rather, to be indicative of overallfunctionality generally required to implement or execute componentengines. That is, one or more of the above functions may be incorporatedinto the object manager layer. The present invention also advantageouslycombines the visual classes and C++ classes into the engine objectcomponent to further standardize and/or provide access to the objectmanager for engine object components.

The present invention optionally uses the standard ActiveX componentcontrol supplied, for example, by MicroSoft Corporation. ActiveX is aprotocol for component communication. The present invention also createseach of the object manager and the engine component layer as a separateActiveX. That is, the object manager is its own ActiveX control, and theengine object is its own ActiveX control. Thus, the engine object cannow run independently from the object manager. Accordingly, the engineobject can operate without relying necessarily on the concurrentoperation of the object manager.

The independent relationship between the engine object and the objectmanager means also that the engine object represents a discrete means oftechnology. For example, an engine object can be an OCR technology. Thisprovides several benefits. First, because the object manager layer isopen, the manufacturer of the OCR technology can wrap their own enginein the form of an engine object component, and the engine willautomatically “plug into” or work with, the object manager. Thus, theengine object is provided high level access, making it accessible tomany more parties, users, and the like. When the object managerinterface is designed to be open, any third party, such as an enginemanufacturer, can create their own engine object component that iscompatible with the object manager, the manufacturer can do it.

FIG. 19 is an illustration of a distributed environment or architecturefor manually and/or automatically generating and/or using reusablesoftware components for client server and/or intranet operatingenvironments. A very significant point that is relevant to why theobject manager and the engine object component are independent in thepresent invention relates to providing a distributed environment forusing the present invention. Rather than communicate within the sametechnology between the object manager and the engine object, the objectmanager and the engine object component communicate with each other inbinary mode, via, for example, standard distributed component objectmodule (DCOM) communication. As illustrated in FIG. 19, object manager14 communicates with engine object component 16, 18, 20 via DCOMspecification 166. Other types of component communication may also beutilized that provide the capability of a distributed componentinteraction.

Thus, the engine object component and the object manager can leveragecurrent protocols to not only communicate on the same machine, but alsoon different machines such as a client server and/or intranet and/orInternet environment. The object manager can be placed on one machine,and the engine object component on another machine and have distributedprocessing, what is otherwise called thin client processing, distributedprocessing, wide area intranet processing.

What this allows the present invention to do is to put the objectmanager on the thin client, who would accept the request from the user,for example, to OCR something or to print something. The actual requestis handled or processed by the engine object component which generallyresides on the server. The engine object component contains the horsepower, or the processing power to process the request.

The engine object layer is generally located in the same orsubstantially same location as where the core technology or engineitself is being stored. Alternatively, the engine object layer and theengine may be optionally located in a distributed environment ondifferent machines, servers, and the like.

FIG. 20 is a detailed illustration of the distributed environment orarchitecture for manually and/or automatically generating and/or usingreusable software components for client server and/or intranet operatingenvironments. In FIG. 20, client 170 includes object manager layer 172.Client 170 executes the core technology 180, via accessing engine objectlayer 178 managed/stored on server 176, and communicated via server 174.

Client 182, located on the same server 176 as core technology 180 andengine object layer 178, may also be used to execute the core technology180 via object manager layer 184. In this instance, the client 182 withthe object manager layer 184 is located on the same server 176 as theengine object layer 178. In addition, since the present inventionutilizes a communication protocol between components, for example, DCOM,that allows a client to also include both the engine object componentlayer and the object manager layer on the same machine 186, as well asthe core technology.

Further, since the object manager is formatted or constructed of aclient technology, the object manager can sit in a standard browser.This means that anyone that has an Internet browser, i.e., anyone thathas access to the world wide web (WEB) can actually access the coreengine technology. Thus, by structuring the architecture of the presentinvention as described herein, users automatically become Internet,intranet and/or WEB enabled.

The present invention also transforms the core technology fromessentially client based technology into a client server and/or a thinclient technology. This makes the core technology high level accessible,thereby transforming any core technology into client server, or hiddenclient technology. The browser is located on the client, and the browserleverages the object manager. Accordingly, the browser optionallycontains the object manager, and the object manager makes requests over,for example, the Internet, local network, and the like via a server, tothe engine object. The server would be either a web server or a LANserver.

The present invention also advantageously provides the ability to havethe client and the server, in a distributed environment as discussedabove, or on the same machine locally. The present invention utilizesthe DCOM communication protocol defining the communication protocolbetween the object manager and the engine object component. Accordingly,since DCOM can work on the same machine as well as in a distributedenvironment, DCOM does not necessitate that the engine object or theobject manager component be on two separate machines.

FIG. 21 is an illustration of a distributed environment or architecturefor manually and/or automatically generating and/or using reusablesoftware components for network environments, such as the Internet. Asillustrated in FIG. 21, object manager 14 communicates with engineobject component 16, 18, 20 via DCOM specification and a networkingenvironment, such as the Internet, intranet, and the like 168. Othertypes of component communication may also be utilized that provide thecapability of a distributed component interaction over a networkingenvironment.

FIG. 22 is a detailed illustration of the distributed environment orarchitecture for manually and/or automatically generating and/or usingreusable software components in the Internet environment. In FIG. 22,client 170 includes object manager layer 172. Browser/thin client 170 aexecutes the core technology 180, via accessing engine object layer 178managed/stored on web server 176 a, and communicated via the Internet174 a.

Browser/thin client 182 a, located on the same web server 176 a as coretechnology 180 and engine object layer 178, may also be used to executethe core technology 180 via object manager layer 184. In this instance,the browser/thin client 182 a with the object manager layer 184 islocated on the same web server 176 a as the engine object layer 178. Inaddition, since the present invention utilizes a communication protocolbetween components, for example, DCOM, that allows a client to alsoinclude both the engine object component layer and the object managerlayer on the same machine 186, as well as the core technology.

FIGS. 23A-23C are illustrations of the image viewer user selectable orconfigurable or programmable interface and/or functionality associatedtherewith in accordance with the present invention. In FIG. 23A, userinterface 200 for image viewing includes viewing frame 202, with dualviewing areas 204, 206. Viewing area 204 includes at the periphery,previous page activator 208, at the top, document tools 210, and at thebottom status indicator 214. Viewing area 206 includes at the periphery,next page activator 212, at the top, document tools 214, and at thebottom status indicator 216.

Advantageously, this user interface is selectable and/or customizable bythe user, as illustrated below in connection with this figure and FIGS.23B-23C. Significantly, the image viewer provides the ability to a userto retain or develop a specific perspective on viewing a document. Oneof the features of the viewer is therefore the ability to change theuser's perspective. For example, the user might be looking at the samedocument, as a book, as a film, or as a bounded or traditional book.This gives the user the ability to relate to the document in a fashionthat they are comfortable with, depending on the content or depending onthe user. That is, the image viewer is like a usable selectableperspective on viewing a document in a plurality of ways.

FIG. 23B is an illustration of another user selectable interface forimage viewing. In FIG. 23B, user interface 200′ for image viewingincludes viewing frame 202′, with single viewing area 204′. Viewing area204′ includes at the top left, previous page activator 208′ and at thetop right next page indicator 212′. Viewing area 204′ also includes atthe left area document tools 210′, and at the bottom status indicator214′. Viewing area 204′ also includes at the top, multiple viewing pagearea 218, that appears and preferably moves like a film, and providesviewing of multiple consecutive or non-consecutive pages.Advantageously, this user interface is selectable and/or customizable bythe user, as illustrated below in connection with this figure and FIG.23A and FIG. 23C. FIG. 23C is an illustration of another user selectableinterface for image viewing. In FIG. 23C, user interface 200″ for imageviewing includes viewing frame 202″, with single viewing area 204″.Viewing area 204″ includes at the top right, previous page activator208″ and at the bottom left next page indicator 212″. Viewing area 204″also includes at the left area document tools 210″, and at the bottomstatus indicator 214″. Viewing area thus provides a user interface toview a document that appears like a bound or more traditional book.Advantageously, this user interface is selectable and/or customizable bythe user, as illustrated below in connection with this figure and FIGS.23A-23B.

FIG. 24 is an illustration of a stand-alone and/or distributedenvironment or architecture for image viewer in client server and/orintranet operating environments. The architecture in FIG. 24 providesthe capability to perform the viewer process off-line. That is, theviewer process 188 provides an added feature on top of the objectmanager layer 14. As described above, object manager layer 14 isessentially an interface, and the viewer process 188 is an applicationthat leverages the object manager layer 14.

The advantage of the viewer process 188 being built on the objectmanager layer 14, which is built on top of the engine object layer 16,18, 20, is that the viewer process can offset its processingcapabilities anywhere in a distributed environment. It can have theprocessing occur at the local station, on a server, and the like, asdescribed below in detail. Significantly, the object manager and theengine object component are independent to provide a distributedenvironment for using the present invention. Rather than communicatewithin the same technology between the object manager and the engineobject, the object manager and the engine object component communicatewith each other in binary mode, via, for example, standard distributedcomponent object module (DCOM) communication.

As illustrated in FIG. 24, object manager 14 communicates with engineobject component 16, 18, 20 via DCOM specification 166. Other types ofcomponent communication may also be utilized that provide the capabilityof a distributed component interaction. Object manager 14 is alsorespectively connectable to viewer process 188.

Thus, the engine object component and the object manager can leveragecurrent protocols to not only communicate on the same machine, but alsoon different machines such as a client server and/or intranet and/orInternet environment. The object manager and/or viewer process can beplaced on one machine, and the engine object component on anothermachine and have distributed processing, what is otherwise called thinclient processing, distributed processing, wide area intranetprocessing.

What this allows the present invention to do is to put the objectmanager on the thin client, who would accept the request from the user,for example, to perform the viewer process. The actual request ishandled or processed by the engine object component which generallyresides on the server. The engine object component contains the horsepower, or the processing power to process the request.

The engine object layer is generally located in the same orsubstantially same location as where the core technology or engineitself is being stored. Alternatively, the engine object layer and theengine may be optionally located in a distributed environment ondifferent machines, servers, and the like.

FIG. 25 is a detailed illustration of a stand-alone and/or distributedenvironment or architecture for image viewer in client server and/orintranet operating environments. In FIG. 25, client 170 includes objectmanager layer 172 with viewer process 192. Client 170 executes the coretechnology 180, via accessing engine object layer 178 managed/stored onserver 176, and communicated via server 174. Viewer process 190 is alsooptionally available to either or both servers 174, 176.

Client 182, located on the same server 176 as core technology 180 andengine object layer 178, may also be used to execute the core technology180 and/or viewer process 192 via object manager layer 184. In thisinstance, the client 182 with the object manager layer 184 is located onthe same server 176 as the engine object layer 178. In addition, sincethe present invention utilizes a communication protocol betweencomponents, for example, DCOM, that allows a client to also include boththe engine object component layer, viewer process 194 and the objectmanager layer on the same machine 186, as well as the core technology.

Further, since the object manager is formatted or constructed of aclient technology, the object manager can sit in a standard browser.This means that anyone that has an Internet browser, i.e., anyone thathas access to the world wide web (WEB) can actually access the coreengine technology and/or viewer process. Thus, by structuring thearchitecture of the present invention as described herein, usersautomatically become Internet, intranet and/or WEB enabled.

The present invention also transforms the core technology and/or viewerprocess from essentially client based technology into a client serverand/or a thin client technology. This makes the core technology highlevel and/or viewer process accessible, thereby transforming any coretechnology and./or viewer process into client server, or hidden clienttechnology. The browser is located on the client, and the browserleverages the object manager. Accordingly, the browser optionallycontains the object manager, and the object manager makes requests over,for example, the Internet, local network, and the like via a server, tothe engine object. The server would be either a web server or a LANserver.

The present invention also advantageously provides the ability to havethe client and the server, in a distributed environment as discussedabove, or on the same machine locally. The present invention utilizesthe DCOM communication protocol defining the communication protocolbetween the object manager and the engine object component. Accordingly,since DCOM can work on the same machine as well as in a distributedenvironment, DCOM does not necessitate that the engine object or theobject manager component be on two separate machines.

FIG. 26 is an illustration of a stand-alone and/or distributedenvironment or architecture for image viewer in network environments,such as the Internet. As illustrated in FIG. 21, object manager 14communicates with engine object component 16, 18, 20 via DCOMspecification and a networking environment, such as the Internet,intranet, and the like 168. In addition, object manager layer 14 alsoadvantageously communications with viewer process 188 a. Other types ofcomponent communication may also be utilized that provide the capabilityof a distributed component interaction over a networking environment.

FIG. 27 is a detailed illustration of a stand-alone and/or distributedenvironment or architecture for image viewer in the Internetenvironment. In FIG. 27, client 170 includes object manager layer 172.Browser/thin client 170 a executes the core technology 180 and/or viewerprocess 192 a, via accessing engine object layer 178 managed/stored onweb server 176 a, and communicated via the Internet 174 a. Viewerprocess 190 is also optionally available to web server 176 a.

Browser/thin client 182 a, located on the same web server 176 a as coretechnology 180, viewer process 192 a and engine object layer 178, mayalso be used to execute the core technology 180 via object manager layer184. In this instance, the browser/thin client 182 a with the objectmanager layer 184 is located on the same web server 176 a as the engineobject layer 178. In addition, since the present invention utilizes acommunication protocol between components, for example, DCOM, thatallows a client to also include both the engine object component layerand the object manager layer on the same machine 186, as well as thecore technology and viewer process.

The purpose of the Virtual Copier (“VC”) aspect of the present inventionis to enable a typical PC user to add electronic paper processing totheir existing business process. VC is an extension of the concept weunderstand as copying. In its simplest form it extends the notion ofcopying from a process that involves paper going through a conventionalcopier device, to a process that involves paper being scanned from adevice at one location and copied to a device at another location. Inits more sophisticated form, VC can copy paper from a device at onelocation directly into a business application residing on a network oron the Internet, or visa versa. The VC invention is software thatmanages paper so that it can be electronically and seamlessly copied inand out of devices and business applications (such as Microsoft Office,Microsoft Exchange, Lotus Notes) with an optional single-step Gooperation. The VC software can reside on a PC, LAN/WAN server, digitaldevice (such as a digital copier), or on a web server to be accessedover the Internet.

Virtual Copier is designed to solve the corporate paper problem byenabling existing web-based and client-server applications to managepaper as part of their solution. Virtual Copier links the familiar anduniversal world of paper and digital devices to web-based andclient-server applications. The result is that the automated businessprocesses become the primary storage of paper in electronic form.Information that is typically managed and processed in paper form is“copied” into the system and managed by the business processes withwhich users are accustomed, which is made possible by using VirtualCopier. Simple extensions of Virtual Copier support seamless electronicoutsourcing of paper processing and archival services over the web.

Virtual Copier is a unique combination of an intuitive application builton an open component architecture that delivers a simple innovation:provide paper processing to existing Intranet and client-server businessprocesses without any fuss. Whether it is an office clerk that needs toeasily copy a report from a desktop scanner to the company'sIntranet-networked copier, or an accounting software integrator thatwants to embed paper processing, Virtual Copier offers a simplesolution. To the office clerk Virtual Copier is a document imagingapplication packaged in the familiar setting of an office copier. To theintegrator, the underlying open architecture of Virtual Copier offers asimple integration path for embedding paper processing into itsclient-server or web-based software solution.

Although managing paper manually is one of the great problems facingcorporations, there has been little innovation in enabling those workersto eliminate the need to continuously work with paper manually. Much ofthe problem stems from the complexity of traditional document managementsystems, which require days of training and months to become familiarwith the system in order to be proficient. Virtual Copier was designedto be as simple as a copier to operate, and yet still provide thecomplete capability of integrating paper with existing businessapplications. By simplifying the interface and underlying softwareinfrastructure, VC can manage paper in electronic form as easily as iscurrently done in physical form.

VC extends the notion of a copier, which simply replicates the image ofan original document onto another piece of paper using a single GO orSTART button, to do a similar operation in software so that the imagegets seamlessly replicated into other devices or applications or theInternet.

An example of this is the actual implementation of Virtual Copier as aconsumer product. As shown in FIGS. 28 and 29, the interface of theconsumer product called Virtual Copier has a Go button much like aphysical copier. This GO button can copy paper, whether physical orelectronic, from one device and or application to another device and/orapplication.

What makes Virtual Copier as simple as its physical counterpart in atleast one embodiment is the fact that it replicates the identicalmotions that a user who is making a copy using a physical photocopiergoes through. When a user photocopies a document, he/she selects wherethey want to copy from (i.e. the sheet feeder), where the user wants tocopy to (i.e. 6 copies collated and stapled) and then presses a GObutton to actually carry out the photocopy process. With Virtual Copierthe process feels familiar because the sequence is the same asillustrated in FIG. 30 with just the Power VC portion of the mainVirtual Copier window.

The power of Virtual Copier is the fact that the From can be a physicaldevice (e.g. digital copier, fax or scanner) or an application (e.g.Lotus Notes, Microsoft Exchange, the Internet, or an electronic filingsystem). The To can also be a physical device (e.g. a fax, digitalcopier, or printer) or an application (e.g. Lotus Notes, MicrosoftExchange, the Internet, or an electronic filing system). Even thoughpaper is being copied electronically from devices to applications, fromapplications to devices, from devices to devices, or from applicationsto applications, the user simply has one sequence to execute: selectFrom, select To, and then press GO. Virtual Copier will accomplish alltranslations between device and applications automatically andseamlessly.

Another reason that paper is still a major corporate issue is thattraditional document management systems require that a company invest ina whole new system just to store electronic images. Although this is theonly way that document management systems have been designed anddelivered, it is in fact highly inefficient. Most companies alreadymanage information about physical documents in some form of softwareapplications.

For example, accounting systems have long been used to maintaininformation about invoices and bills that arrive into a company fromoutside sources as physical pieces of paper. When an invoice arrives,its information is keyed into the accounting software, where balancesare maintained and accounts payable information is coordinated. Yet theoriginal invoice is stored manually, and every time that a request ismade for a copy of the signed invoice, someone manually retrieves theinvoice from a physical filing cabinet. Accounting systems, like mostbusiness applications, typically have no way of maintaining anelectronic copy of the physical invoice, and adding a documentmanagement system to an accounting system is cumbersome, costly, anddifficult to maintain, and even more difficult to coordinate.

Virtual Copier solves this problem in at least one embodiment by copyingpaper directly into the existing accounting system. Simply adding a Toitem in the Virtual Copier window enables a user to copy paper directlyinto the appropriate accounting record of the existing accountingsystem. This requires no retraining (users who are trained on theaccounting system will still use the accounting system in the same way),requires no document management system (the electronic copy of thedocument is actually being maintained by the accounting system itself),there is no coordination between two systems (Virtual Copier embeds theinvoice with the appropriate accounting record), and it is simple (oneGo button).

What is true with regard to the example above of an accounting system istrue of most other business applications. The power of Virtual Copier isthat it can turn an information system into a document management systemby adding support for electronic paper directly into the existingbusiness application, whether it is a client, server-based, or web-basedsystem.

Virtual Copier enables corporations to perform sophisticated documentimaging with their existing Web-based and client-server applicationsthrough a user interface that is as familiar as the office copier.Virtual Copier can be used out-of-the-box as a standalone application tocopy, scan, fax, or print images using existing digital devices withincorporate environments or across the web. With the extensions, asdescribed below, Virtual Copier can be integrated into Web-based andclient server applications, such as ERP or accounting systems, toeliminate paper from existing business processes and legacyapplications. Virtual Copier can also be used to support seamless accessto document image processing and archival over the web since, in atleast one embodiment, the VC interface is implemented as a softwareapplication.

VC is architected as an application that delivers end-user functionalitywhile remaining open to third-parties extensions. For example, VC can beviewed as a copier. Like a copier, VC takes paper in, and produces papergoing out. The only difference is that VC does not distinguish betweenelectronic and physical paper.

To accommodate third-party extensions, VC is divided into five essentialmodules. Each module is a counterpart to an aspect that is found on aconventional copier. Based on the modular design of VC, each aspect ofVC can be independently extended, offering much greater flexibility thanconventional copiers.

The five core modules of VC illustrated in FIG. 31 are:

Input Module—The Input Module manages paper or electronic paper enteringVC. This module manages imaging devices to input paper through scanners,MFPs, or the new breed of digital copiers. The Input Module also managesreading electronic paper from third-party or proprietary applications.The counterpart to VC's Input Module on a conventional copier is thescanner subsystem.

Output Module—The Output Module manages paper or electronic paperexiting VC. Like the Input Module, this module manages imaging devicesto output paper to standard Windows printers, specialty image printers,MFPs, or the new breed of digital copiers. The Output Module alsomanages writing electronic paper to third-party or proprietaryapplications. The counterpart to VC's Output Module on a conventionalcopier is the printer or fax subsystem.

Process Module—The Process Module applies processing to the electronicpaper as it is being copied. Examples of a process are OCR and ICR. TheProcess Module can also apply non-imaging functionality as well, such asworkflow or other relevant tie-ins to the electronic paper as it isbeing copied. One of the advantages of VC over conventional copiers isthat multiple processes can be applied to a single virtual copy. Thecounterpart to VC's Process Module on a conventional copier is thecontroller.

Client Module—The Client Module presents the electronic paper as it isbeing copied, and any relevant information related to the input oroutput functions. For example, if the Output Module is directed to aprinter, then the Client Module might present the finishingcapabilities; if the Output Module is directed to Goldmine, then theClient Module might present the target contact record to which thedocument is being copied. The counterpart to VC's Client Module on aconventional copier is the panel.

Server Module—Unlike conventional copiers, VC's Server Module is aunique subsystem that can communicate with the other modules as well asthird-party applications. The Server Module is what makes VC a far morepowerful concept than simply an application that can control a scannerand a printer to mimic a copier. The Server Module can be used tocombine third-party applications with the new breed of digital imagingdevices to create unique and custom virtual copier solutions. A virtualcopier can be created with VC by combining a scanner with a printer; orby combining a scanner with an application; or by combing an applicationwith an image printer. In each case VC is dynamically creating a customvirtual copier, with a complete understanding of how paper flows fromthe source to its destination. There is no counterpart to VC's ServerModule on a conventional copier.

One of the primary design goals of VC is to make it simple to integrateVC with third-party applications. There are two options to integratingVC into a third-party application: running VC as an external service, orembedding VC as an underlying service.

VC is in one embodiment and optionally a standalone application thatenables a user to scan (copy) paper from a device to a third-partyapplication, and to print (copy) the reference of an image document froma third-party application to a printing device. VC does not require thethird-party application to be aware that VC is operating. Rather, VCrecognizes that the third-party application is running, and itintelligently copies paper to and from that application as illustratedin FIG. 32.

In this scenario the user is interacting with VC's Client Module inorder to execute a copy operation to and from the third-partyapplication. There does not have to be any changes made to thethird-party application, not even to its interface, in order for VC tooperate. The user of VC only knows that to copy to and from thethird-party application, a custom Input and Output Module must beselected, and the Go button is pressed.

In order to support copying to and from a third-party application, VCmust be able to support extensions that understand each third-partyapplication. This is accomplished through the Input and Output Modules.The Client, Server, and even Process Modules remain independent acrossthird-party applications. However, in order to support outputting to athird-party application, an Output Module is developed that is unique tothat third-party application. Likewise, an Input Module is developedthat is unique to a third-party application in order to support readingimages from that application.

It is the optional Input and Output Modules that render VC extendable.For each third-party application there is a unique pair of Input andOutput Modules that understand the third-party application, and how tocopy images to and from that application. Each Input and Output Moduleregisters itself to the Windows registry so that the Server Module knowshow to find them. In this way Virtual Copier can grow indefinitely, tosupport any number of third-party applications.

The significant point is that the Input and Output Modules have theirown interface, and can be developed independently from any other module.As long as the Input and Output Module conform to the API specified inthis document it will plug-and-play with VC. VC will be able to mix andmatch the custom Input and Output Module with its standard and othercustom Input and Output Modules.

A third-party application can also use the services of VC without itsuser interface. That is, a third-party application can embed VC'sfunctionality and provide its own interface to its functionality. Forexample, rather than have VC as a separate application, a special buttoncan be placed on a third-party application that launches VC in thebackground as illustrated in FIG. 33.

VC is designed so that the Server Module can run independently from theClient Module. All the core functionality, including communicating withthe Input, Output, and Process Modules, are performed directly by theServer Module. The Client Module is generally simply an interface to theServer Module. Therefore, all the services of the Server Module can bemade available in the background to a third-party application withoutthe need for an interface. The third-party application can in factbecome the user's interface to VC.

In order to support VC operating in the background a third-partyapplication merely has to communicate with the Server Module directly,as described later in this document. The Server Module, as all modulesin VC, support COM-based interfaces for simple and direct support fromall major Windows development environments.

At the heart of VC is the Server Module. A virtual copy operation canonly be initiated using the Server Module. The Server Module coordinatesthe activities of the various modules while maintaining the informationregarding the current process and document. It also collects and passesinformation from one module to another regarding the document andprocess. Events and an API are used to control the modules and theirinteraction with each other as well as with the Server Module.

The following are the main functions of the Server Module:

Enable Virtual Copy Operation—The Server Module provides simple methodsto initiate, cancel, and reset VC. The API is designed to imitate thesimplicity of using a conventional copier.

Maintain List of Available Modules—The Windows registry contains thelist of available Input, Output, and Process Modules that can be usedwith VC. The Server Modules reads this list on startup, and maintains itin the Modules object that can be accessed by the other modules.Although each module can read this information directly from theregistry, it is preferable to use the Modules object. All informationregarding the available modules can be found in the Modules object.

Maintain the Currently Active Modules—The Server Module maintains thecurrent Input, Output, and Process Modules that are being used for thecurrent virtual copy operation. This is maintained in the Programobject. This information can also be saved to disk in a Process Templatefile.

Maintain Complete Document Information—The Server Module maintains allthe information regarding the current file being copied. This ismaintained in the VDocument object. This information can also be savedto disk in a Document Template file.

As with other design elements of VC, the VC logic flow illustrated inFIG. 34 parallels the basic logic flow of a conventional copier. In aconventional copier, paper is pulled into the copier, processed, andoutput. Likewise, in VC the Server Module initiates the Input Module,Process Module, and Output Module in that sequence. Unlike aconventional copier which does not have the ability to update its panel,VC updates its Client Module as well as the results of each Moduleacting on the document as illustrated in FIG. 35.

All actions to create, process, and write images are the responsibilityof the Input, Process, and Output Modules respectively. The ServerModule is a scheduler of activities, providing the information andinitiating the modules at the appropriate time in the virtual copyoperation. The Server Module manages the other Modules. It does not knowabout the internal workings of the modules, nor the contents of theinformation being copied. The Server Module API is sufficiently rich tomaintain all the information necessary for a basic virtual copyoperation.

The Server Module API is divided, for example, into the followingCOM-based interfaces:

Modules Object—This object maintains the list of available Input,Output, and Process Modules

Program Object—This object maintains the currently selected Input,Output, and Process Modules

VDocument Object—This object maintains the information regarding thecurrent document that is being copied

VC Methods—These methods are used to initiate, cancel, and reset VC

VC Events—These events are used to provide feedback to the Client Module

The purpose of the Modules object is to provide the Client Module withthe full list of available Input, Output, and Process Modules that isavailable to the user. The Client Module can obtain the user-readablenames for each module, as well as its icon and other key information.The Modules object is primarily used to seed list or combo boxes thatprovide the end-user with a choice of modules from which to select.

In a preferred embodiment, the Modules Object has, for example, thefollowing structure illustrated in FIG. 36, however, alternativestructures and/or functionality may optionally be used for this objectand/or other objects used in the present invention:

Name Configure Type Method Format .Configure( ) Description TheConfigure method causes the module to prompt the user for configurationinformation. Each module maintains its own configuration dialog, andtherefore may look different than other modules. SampleVCopier.InputModules(1).Configure( ) Name Default Type Property; Objectof type InputModule, OutputModule, or ProcessModule Format .Default -Read Only Description The Default property identifies the default modulethat the Server Module will use at startup or if no other module isidentified. Sample MyInputModule = VCopier.InputModules.Default Name IDType Property; BSTR Format .ID - Read Only Description The ID propertyidentifies the ProgID of a module. The ProgID can be used to deriveother information about the module, including its Icon. SampleModuleName = VCopier.InputModules(1).ID Name File Type Property; BSTRFormat .File - Read Only Description The File property identifies thefull pathname of the physical file of a module. Sample FileName =VCopier.InputModules(1).File Name InputModule, OutputModule,ProcessModule Type Object Format .InputModule, .OutputModule,.ProcessModule - Read Only Description The InputModule, OutputModule,and ProcessModule are the individual objects maintains by theInputModules, OutputModules, and ProcessModules collectionsrespectively. Each one of these objects has the following elements: NameID File Configure The Name property is a BSTR that is the user-readablename of the module. The ID is a BSTR that represents the ProgId of themodule. The File property is a BSTR that is the full pathname of themodule. The Configure method prompts the user with a dialog forconfiguring that module. Sample MyInputModule = VCopier.InputModules(2)Name InputModules, OutputModules, ProcessModules Type Collection ofInputModule, OutputModule, and ProcessModule objects respectively Format.InputModules, .OutputModules, .ProcessModules - Read Only DescriptionThe InputModules, OutputModules, and ProcessModules collections maintainthe list of available modules for each category. Each collectionmaintain the following information:InputModule/OutputModule/ProcessModule Default The first element is theindividual module in the collection of modules that are available to VC.The Default object is the default module that VC uses at startup. TheServer Module maintains these collections under the Modules object.Sample MyInputModule = VCopier.InputModules(2) Name IsLoaded TypeMethod, Boolean Format .IsLoaded( ) Description The IsLoaded methodreturns True if the module is loaded into memory, and False if it isnot. Sample ModuleName = VCopier.InputModules(1).IsLoaded Name Load TypeMethod Format .Load( ) Description The Load method manually loads themodule into memory. Once a module is loaded in VC it remains in memoryuntil it is specifically unloaded using the Unload method, or theprogram exits. Sample ModuleName = VCopier.InputModules(1).Load NameName Type Property, BSTR Format .Name - Read Only Description The Nameproperty identifies the user-readable name of a module. This name can beused in a list box for a user to select the module. Sample ModuleName =VCopier.InputModules(1).Name Name ResetSettings Type Method Format.ResetSettings( ) Description The ResetSettings method returns thesettings of the module back to its original state when the VC firstcalled it. A user can change the settings of a module when it isconfigured. This method is used to role back changes made bu a userduring the VC session. To save the settings between sessions, use theSaveSettingsAsDeafult method. Sample ModuleName =VCopier.InputModules(1).ResetSettings( ) Name SaveSettingsAsDefault TypeMethod Format .SaveSettingsAsDefault( ) Description TheSaveSettingsAsDefault method save any changes to the settingst the userhas done during this session to disk so that they become the newsettings. Sample ModuleName = VCopier.InputModules(1).ResetSettings( )Name Unload Type Method Format .Unload( ) Description The Unload methodmanually unloads the module from memory. Once a module is loaded in VCit remains in memory until it is specifically unloaded using the Unloadmethod, or the program exits. Sample ModuleName =VCopier.InputModules(1).Unload( )

The Program Object maintains the currently selected Input, Output, andProcess Modules. It is generally set by the Client Module based on inputfrom a user. However, in applications that do not have a user interfacethe program object can be used to directly set the modules to run VC.The Program Object has the following structure illustrated in FIG. 37.

All elements of the Program Object are defined in the Modules Objectsection. The VDocument Object maintains information about the currentdocument being copied. The VDocument represents a virtual documentrather than a physical one. It is designed to allow the flexiblemanagement of multi-image files that together constitute an document.The internal VDocument maps to physical files as illustrated in FIG. 38.

The VDocument Object calculates the total number of pages of all thefiles associated with it, and lays out each page of each document in asingle virtual document. As the figure illustrates, if 4 files contain atotal of 8 pages, then VDocument considers this an 8 page document. Ifthe 6th page is requested, VDocument will return the second page of FileC in the above figure. This enables VDocument to handle single pagefiles that together constitute a document (as is the case with many ofthe new digital copiers), or a single multi-page image file, or anycombination of the two. The VDocument Object is illustrated in FIG. 39and below.

Name Add Type Method Format .Add(BSTR File, Long Page) Description TheAdd method is used to add a page to the VPages collection. The twoarguments File and Page represent the disk file and the page number toassociate with the new page in VPages. One page of one file is added ata time using this method. Sample VDocument.Add(FileA, 2) Name AutoDeleteType Property, Boolean Format .AutoDelete Description The AutoDeleteproperty lets the Server Module know whether to delete the files oncethe virtual copy operation is completed. When set to True the ServerModule will delete the physical disk files maintained in Vdocumenteither before the next virtual copy operation, or when VC is shut down.When set to False Vdocument is cleared of its contents between virtualcopy operations, but the actual files are not deleted from the disk. Ingeneral if the VDocument object points to existing files then AutoDeleteshould be set to False. If the VDocument object points to temporaryfiles, then AutoDelete should be set to True so that the disk files arecleaned up (i.e. deleted) by the Server Module. By default AutoDelete isset to False. Sample VCopier.VDocument.AutoDelete = True Name Clear TypeMethod Format .Clear( ) Description The Clear method is used to emptythe contents of the Vdocument object. The VPages object is emptied andthe reference to files are deleted in conformance with the AutoDeleteproperty. Sample VDocument.Clear( ) Name File Type Property, BSTR Format.File Description The File property of the VPage object points to thedisk file that contains the image associated with the VPage page. SampleMyFile = VDocument.VPages(2).File Name Page Type Property, Long Format.Page Description The Page property of the VPage object points to theimage offset into the disk file that contains the image associated withthe VPage page. Sample MyPage = VDocument.VPages(2).Page Name RemoveType Method Format .Remove( ) Description The Remove method is used toremove a page from the VPages collection. The single argument Index isthe offset page into the VPages collection. SampleVDocument.VPages(2).Remove( ) Name Vpage Type Object Format .VpageDescription Each VPage object represents a single virtual page in theVDocument object. Each VPage object contains the name of the file thatcontains its virtual page in the .File property, and a .Page propertywhich is the page offset in the image file. Sample MyPage =VCopier.VPages(2) Name Vpages Type Collection of Page objects Format.Vpages Description The VPages collection contains one VPage object pervirtual page. Each page of each image file that is tracked by VDocumentis considered a unique page, and its information is maintained by aVPage object. Sample MyPage = VCopier.VPages(2)

The Server Module supports simple methods that accomplish the basiccopier functionality of go, cancel, and reset. The Server Modules hasthe following structure:

Name Cancel Type Method Format .Cancel( ) Description The Cancel methodis used to cancel the currently running virtual copy operation. TheCancel method can only be used once the Go method is called and prior toits completion. Sample VCopier.Cancel( ) Name Go Type Method Format .Go() Description The Go method is used to initiate a virtual copyoperation. It calls the modules in the following sequence:Program.InputModule, Program.ProcessModules, and thenProgram.OutputModule. The virtual copy operation can be cancelled priorto its completion by calling the Cancel method. Sample VCopier.Go( )Name Reset Type Method Format .Reset( ) Description The Reset method isused to clear the contents of the Program object. After calling theReset method VC is considered to have no assigned Input and Outputmodules selected. The modules that are reset are not unloaded frommemory. Sample VCopier.Reset( )

The are two events that the Server Module supports: Error and Status.The Error event is generated anytime any of the Modules produce an errorcondition. The Status event is generated when information needs to betransferred between the IOP or Server Modules and the Client Module.

The following are details for each event, illustrated in FIGS. 40 and 41and below.

Name Error Type Event Format .Error( . . . ) Description The Error eventis triggered whenever there is an error by one of the modules. The errorcan be trapped and displayed or processed by the Client Module. SampleName ErrorCode Type Argument, Long Format .ErrorCode Description TheErrorCode argument of the Error event identifies the actual error code.There are no predefined error codes for all modules. Each moduleproduces its own set of error codes. Sample Name ErrorText TypeArgument, BSTR Format .ErrorText Description The ErrorText argument ofthe Error event identifies the actual error text. There are nopredefined error texts for all modules. Each module produces its owntext for its error codes. Sample Name ModuleID Type Argument, BSTRFormat .ModuleID Description The ModuleID argument of the Error eventidentifies the source of the error condition. The ModuleID is defined asthe version-dependent ProgID. Sample Name Severity Type Argument, LongFormat .Severity Description The Severity argument of the Error eventidentifies the level of error condition. The following levels arecurrently implemented: 1—Severe 2—Warning Sample Name SubModuleID TypeArgument, BSTR Format .SubModuleID Description The SubModuleID argumentof the Error event identifies the secondary source of the errorcondition. The SubModuleID can defined as the version-dependent ProgID,or any other value determined by the Module that generates the errorcondition. Sample Name URL Type Argument, BSTR Format .URL DescriptionThe URL argument of the Error event identifies the URL address (website, HTML file, or resource file URL), that contains the HTMLrepresentation of the error condition. The information presented can bemore dynamic as well as formatted than the ErrorText argument. SampleName Info1, Info2 Type Argument, Variant Format .Info1, .Info2Description The Info1 and Info2 arguments of the Status event areplaceholders for additional information that needs to be supplied withspecific status numbers. Sample Name Status Type Evenet Format .Status(. . . ) Description The Status event is triggered by any of the moduleswhen there is information that needs to be relayed to the user or theClient Module. Sample Name StatusNumber Type Argument, Long Format.StatusNumber Description The StatusNumber argument of the Status eventidentifies the actual status code. The values between 1 and 1000 areprivate and cannot be generated by an IOP Module for private use. Anyother status numbers are open for private IOP Module use. Sample NameStatusText Type Argument, BSTR Format .StatusText Description TheStatusText argument of the Status event identifies the actual statustext. Sample Name StatusType Type Argument, BSTR Format .StatusTypeDescription The StatusType argument of the Status event identifies thetype of status. 1—Informational 2—Instruction Sample

The Server Module broadcasts the Status event to the Client Module.There are standard status events that the Server Module generates whichthe Client Module can rely on. These are the events that manage the flowof modules and user interaction with the Server Module. The following isa general workflow of the events that are generated is illustrated inFIG. 42.

-   -   The Server Module generates the following Status events:

StatusNumber StatusText Description VseModuleCanceled The IOP Modulecanceled the operation by setting the Cancel argument in theFeedback.Error or Feedback.Status methods to True VseModuleConfigureEndThe IOP Module has completed presenting its configuration dialogVseModuleConfigureStart The IOP Module has started presenting itsconfiguration dialog VseModuleGoEnd The IOP Module has ended executingVseModuleGoStart The IOP Module has started executing VseModuleLoadEndThe IOP Module has completed loading VseModuleLoadStart The IOP Modulehas started loading VseModuleUnloadEnd The IOP Module has completedunloading VseModuleUnloadStart The IOP Module has started unloadingVseProgramCanceled The Server Module has canceled executing (using the.Cancel method) VseProgramEnd The Server Module has ended executingVseProgramStart The Server Module has started executing a Go operation

The Client Module presents to the user information regarding the copyprocess, and initiates the virtual copy through the Server Module. TheClient Module can be a GUI that Imagination Software develops, or athird-party application that directly communicates with the ServerModule. The goal of the Client Module is to capture sufficientinformation and pass that information along to the Server Module inorder to initiate a single virtual copy.

The Client Module follows the following general logic flow illustratedin FIG. 43. The first step for the Client Module is to determine thatthe Server Module exists, and to successfully launch the Server Module.This is done using a standard COM interface.

If the Client Module is a GUI then it can present icons and the names ofall the available Input, Output, and Process Modules for the user toselect. The Client Module does not need to know any information aboutthese modules. All names and ProdId's are available from the ServerModule API using the Modules Object.

If the user selects a new Input or Output module, the Client Moduleupdates the appropriate Program.InputModule, Program.OutputModule, orProgram. Process Modules object available on the Server Module.

At any time the Client Module can initiate the Go method of the ServerModule. This is a synchronous process—once the Go method is initiatedthe only way to stop it is to call the Cancel method. Only one Go methodcan be called at a time, and it must run to completion before anotherone is called.

During the virtual copy, the Server Module will send back Status andError events that should be processed and displayed (if there is a GUI)by the Client Module. The only requirement for a Client Module is thatit at least substantially conforms to the interface described in theServer Module section. The architecture described in this section, andits associated sample source code, is designed to facilitate developmentof Client Modules by third parties. It should be used as a guide fordeveloping a Client Module—it is not the only way a Client Module can bedesigned.

The internal architecture described below is generally independent fromthe interface requirements for a Client Module. The Client interfacemust be implemented regardless of whether or not the Client is designedwith the architecture described in this section. The basic Clientarchitecture is illustrated in FIG. 44.

The Input, Process, and Output (“IOP”) Modules extend VC by enablingspecialized hardware and software to interact with VC. Each IOP Moduleunderstands the input, output, or processing capabilities of a specifictechnology, as well as how to communicate with the Server Module. Inthis way an IOP Module can read or write images to and from any deviceor software application while still being managed by the Server Module.To the user of VC, interacting with any device or software applicationis the same.

The IOP Modules share a common API to facilitate communication with eachother, with the Server Module, as well as with third-party programs. Theinterface is based on COM. Both the Server Module as well as third-partyapplications can communicate with the Input, Process, and Output Modulesusing the specified COM interface. Additionally, third-party vendors cancreate their own versions of the Input, Process, and Output Modules aslong as they conform to the specified COM interface.

The following are the main functions of the Input, Process, and Output(“IOP”) Modules:

Respond to Server Module Go( ) Method—The Server Module calls the othermodules using a COM-based Go( ) method. All necessary informationregarding the virtual copy operation is passed along using arguments ofthe Go( ) method. The IOP module can then handle its internal operationindependent of any other module.

Generate Status & Error Feedback—The IOP module should let the ServerModule know its progress, error conditions, or any other useful processor userbased information.

Initiate Communication With the Server Module—The IOP Module can at anytime initiate communication with the Server Module to provide newinformation. This enables the IOP Module to pole the device or softwareapplication that it is linked to, and convey that information back tothe Server Module.

The API for the Input, Process, and Output Modules are deliberately madesimple so that third-party vendors can create their own custom versionsof these modules with relative ease. The API, illustrated in FIG. 45,consists of the following COM-based interface:

Go(VDocument, Feedback)—This is the single method that initiates amodule to complete its phase of the virtual copy. The Go( ) method iscalled by the Server Module when it is ready to execute thefunctionality of the module. The two parameters are the VDocumentobject, which contains the information about the current document beingcopied. The module can update the VDocument with additional images, asis typical of an Input Module, or simply read and process the document,as is typical of an Output Module. The second parameter is a Feedbackobject, which contains the two events that the IOP module can generateback to the Server Module.

Name Configure Type Method Format .Configure( ) Description TheConfigure method causes the module to prompt the user for configurationinformation. Each module maintains its own configuration dialog, andtherefore may look different than other modules. SampleMyInputModule.Configure( ) Name Go Type Method Format .Go(Vdocument,Feedback) Description The Go method is called by the Server Module toinitiate the IOP module to execute its part of the virtual copyoperation. The Vdocument Object is passed along as an argument so thatthe IOP module can add to or read the current document that is beingprocessed. Refer to the Server Module section for a complete descriptionof the VDocument object. The second parameter of the Go method is aFeedback object. The Feedback object enables the IOP module to sendstatus and error updates back to the Server Module. These events arealso described in the Server Module section. Sample IOP.Go(VDocument,Feedback) Name ResetSettings Type Method Format .ResetSettings( )Description The ResetSettings method returns the settings of the moduleback to its original state when it was first called. A user can changethe settings of a module when it is configured. This method is used torole back changes made by a user during the VC session. To save thesettings between sessions, use the SaveSettingsAsDeafult method. SampleMyInputModule.ResetSettings( ) Name SaveSettingsAsDefault Type MethodFormat .SaveSettingsAsDefault( ) Description The SaveSettingsAsDefaultmethod save any changes to the settings the user has done during thissession to disk so that they become the new settings. SampleMyInputModule.ResetSettings( )

Module.

The Feedback object illustrated in FIGS. 46-47 is used to communicatebetween the IOP and the Server Module. The Feedback object supports twomethods that are used like events. The purpose of this mechanism is tolimit the communication between the IOP and the Server Module to justthose objects presented to the IOP Module by the Server Module throughthe Go method. In this way the IOP Module is handed all the informationit needs to execute its part of a copy operation.

The Feedback object contains two methods: Error and Status. The Errorevent is used to respond back to the Server Module all error conditions.The Status method is used to communicate back to the Server Module allinformation updates, such as progress.

The following are details for each of these methods:

Name Cancel Type Argument, Boolean Reference Format .Cancel DescriptionThe Cancel argument of the Error method is used to establish whether theServer Module will continue with the virtual copy operation once thisIOP is completed. If set to True then the Server Module will notcontinue its cirtual copy operation. The Server Module will wait untilthe IOP Module returns on its own. The Server Module does not shut downthe IOP Module. Sample Name Error Type Method Format .Error( . . . )Description The Error event is triggered whenever there is an error byone of the modules. The error can be trapped and displayed or processedby the Client Module. Sample Name ErrorCode Type Argument, Long Format.ErrorCode Description The ErrorCode argument of the Error eventidentifies the actual error code. There are no predefined error codesfor all modules. Each module produces its own set of error codes. SampleName ErrorText Type Argument, BSTR Format .ErrorText Description TheErrorText argument of the Error event identifies the actual error text.There are no predefined error texts for all modules. Each moduleproduces its own text for its error codes. Sample Name Severity TypeArgument, Long Format .Severity Description The Severity argument of theError event identifies the level of error condition. The followinglevels are currently implemented: 1—Severe 2—Warning Sample NameSubModuleID Type Argument, BSTR Format .SubModuleID Description TheSubModuleID argument of the Error event identifies the secondary sourceof the error condition. The SubModuleID can defined as theversion-dependent ProgID, or any other value determined by the Modulethat generates the error condition. Sample Name URL Type Argument, BSTRFormat .URL Description The URL argument of the Error event identifiesthe URL address (web site, HTML file, or resource file URL), thatcontains the HTML representation of the error condition. The informationpresented can be more dynamic as well as formatted than the ErrorTextargument. Sample Name StatusText Type Argument, BSTR Format .StatusTextDescription The StatusText argument of the Status event identifies theactual status text. Sample Name StatusType Type Argument, BSTR Format.StatusType Description The StatusType argument of the Status eventidentifies the type of status. 1—Informational 2—Instruction Sample

The only requirement for an IOP Module is that it substantially conformsto the interface described earlier. The architecture described in thissection, and its associated sample source code, is designed tofacilitate development of IOP Modules by third parties. It should beused as a guide for developing an IOP Module—it is not the only way anIOP Module can be designed.

The internal architecture described below is independent from theinterface requirements for an IOP. The IOP interface must be implementedregardless of whether or not the IOP is designed with the architecturedescribed in this section. The basic IOP architecture is illustrated inFIG. 48.

The IOP Module has a fixed set of features that it needs to perform:

Interface with the Server Module

Execute its operation when its Go( ) method is called

Respond to requests by the Server Module to configure its settings

Although any IOP Module that meets the IOP API requirements specifiedearlier will function properly, the proposed architecture simplifies thedevelopment of IOP Modules and ensures greater flexibility.

The internal Interface class has two purposes:

Communicate with the Server Module

Marshall requests to, from, and between the Execute and Configurationclasses

In order to communication with the Server Module the Interface classmust support the COM protocol. All modules within VC communicate viaCOM. This class should be created with the exact API specified earlier.Additionally, the Interface class should maintain the Feedback objectpassed in by the Server Module's Go method. This way all communicationto the Feedback object will be handled by the Interface class, ratherthan by the Execute or Configuration classes.

The primary purpose of the Execute class is to execute the Go methodwhen it is called by the Server Module. This is the core functionalityof the IOP Module. Each IOP Module will have its own mechanism forexecuting its part of a virtual copy operation.

Any configuration information is assumed to have been passed to theExecute class by the time it is being called. Since the Execute classdoes not directly communicate with the Configuration class, anyinformation that needs to be shared between the two classes must becoordinated by the Interface class.

The Configuration class maintains all the configuration data necessaryfor the IOP Module to operate. This includes responding to the ServerModule to:

Prompt the user with a Configuration dialog

Save the current configuration information to persistent storage

Restoring the last saved configuration information from persistentstorage

Since the IOP Module is entirely responsible for these activities, anyprogramming method that accomplishes these tasks is legitimate.

The many features and advantages of the invention are apparent from thedetailed specification, and thus, it is intended by the appended claimsto cover all such features and advantages of the invention which fallwithin the true spirit and scope of the invention. Further, sincenumerous modifications and variations will readily occur to thoseskilled in the art, it is not desired to limit the invention to theexact construction and operation illustrated and described, andaccordingly, all suitable modifications and equivalents may be resortedto, falling within the scope of the invention.

For example, while the above discussion has separated the variousfunctions into separate layers of functionality, the layers may becombined, physically and/or logically, and various functions may becombined together. While combining various functions into same or commonlayers may make implementation details more cumbersome, nevertheless,the functions described herein may still be accomplished toadvantageously provide some or all of the benefits of the inventiondescribed herein.

Further, as indicated herein, the present invention may be used toautomate and/or manually expedite the migration of a program specificApplication Programmer Interface from an original state into a genericinterface by building an object for each engine. The objectadvantageously provides substantially uniform access to the engine andengine settings associated with the engine. The present invention may beapplied across a broad range of programming languages that utilizesimilar concepts as described herein.

What is claimed is:
 1. A method for electronic document management, themethod comprising in any sequential or non-sequential order: storing, ina memory responsively connectable to a computing device, a plurality ofprotocols as a software application; implementing, in the computingdevice, the plurality of protocols to communicate over a network with anexternal application, the external application being executable on anexternal device; receiving a selection of the external application as adestination; receiving an electronic document from an imaging device,the imaging device being operable to convert a paper document into theelectronic document; integrating the electronic document into theexternal application without the need to modify the externalapplication; and transmitting the electronic document to the externalapplication over the network.
 2. The method according to claim 1,wherein transmitting the electronic document to the external applicationover the network comprises using an Application Programmer Interface(API) of the software application.
 3. The method according to claim 1,wherein the imaging device comprises at least one of a multifunctionperipheral a digital copier, or a scanner.
 4. The method according toclaim 3, wherein the software application seamlessly replicates andtransmits the electronic document to a plurality of destination devices.5. The method according to claim 4, wherein the software applicationgenerates a user interface that enables the conversion of the paperdocument into the electronic document between the imaging device and thedestination application using a single “GO” operation.
 6. The methodaccording to claim 3, wherein the external application comprises ane-mail application.
 7. The method according to claim 6, furthercomprising providing information relating to at least one of receivingthe selection, integrating the electronic document or transmitting theelectronic document in response to a user request.
 8. The methodaccording to claim 1, wherein the software application comprises aninput module operable to manage the imaging device to receive theelectronic document from the imaging device.
 9. The method according toclaim 1, wherein the software application comprises an output moduleoperable to transmit the electronic document to the external applicationover the network, wherein receiving the selection of the externalapplication as the destination comprises receiving a selection of theoutput module.
 10. The method according to claim 1, wherein the softwareapplication comprises a process module operable to apply a data processto the electronic document, wherein the data process comprises anoptical character recognition (OCR) process, an intelligent characterrecognition (ICR) process, or a barcode recognition process.
 11. Amethod for implementing including at least one of an electronic image,graphics and document management system capable of transmitting at leastone of an electronic image, electronic graphics or electronic documentto a plurality of external destinations including one or more ofexternal devices or applications responsively connectable via at leastone a local area network (LAN) or via the Internet, the methodcomprising in any sequential or non-sequential order: storing, in atleast one memory, a plurality of interface protocols for interfacing andcommunicating; implementing, by at least one processor responsivelyconnectable to the at least one memory, the plurality of interfaceprotocols as a software application for interfacing and communicatingwith the plurality of external destinations including the one or more ofthe external devices and applications; and integrating the at least oneof the electronic image, the electronic graphics or the electronicdocument into one external destinations among the plurality of externaldestinations without the need to modify the external application. 12.The method according to claim 11, further comprising transmitting the atleast one of the electronic image, the electronic graphics or theelectronic document to the plurality of external destinations includingusing an Application Programmer Interface (API) of the softwareapplication.
 13. The method according to claim 11, wherein the documentmanagement system comprises at least one of a multifunction peripheral adigital copier, or a scanner.
 14. The method according to claim 13,wherein the software application comprises a virtual copier operable toseamlessly replicate and transmit the at least one of the electronicimage, the electronic graphics or the electronic document to theplurality of external destinations.
 15. The method according to claim14, wherein the software application generates a user interface thatenables a conversion of a paper document into the at least one of theelectronic image, the electronic graphics or the electronic documentbetween an imaging device and the plurality of external destinationsusing a single “GO” operation.
 16. The method according to claim 13,wherein the one of the external destinations among the plurality ofdestinations is associated with an e-mail address.
 17. The methodaccording to claim 11, wherein the software application is operable tointerface and communicate with the plurality of external destinationsusing a component object module (COM) interface.
 18. The methodaccording to claim 11, wherein the software application comprises aninput module operable to manage an imaging device to receive the atleast one of the electronic image, the electronic graphics or theelectronic document from the imaging device.
 19. The method according toclaim 11, wherein the software application comprises an output moduleoperable to transmit the at least one of the electronic image, theelectronic graphics or the electronic document to the plurality ofexternal destinations, wherein the method further comprises receiving aselection of one of the external destinations by receiving a selectionof the output module.
 20. The method according to claim 11, wherein thesoftware application comprises a process module operable to apply a dataprocess to the at least one of the electronic image, the electronicgraphics or the electronic document, wherein the data process comprisesan optical character recognition (OCR) process, an intelligent characterrecognition (ICR) process, or a barcode recognition process.
 21. Amethod for electronic document management, the method comprising in anysequential or non-sequential order: storing, in a memory responsivelyconnectable to a computing device, a plurality of protocols as asoftware application, the software application comprising a processmodule; implementing, in the computing device, the plurality ofprotocols to communicate over a network with an external application,the external application being executable on an external device;receiving an electronic document from an imaging device, the imagingdevice being operable to convert a paper document into the electronicdocument; and receiving a selection of a data process, the processmodule being operable to apply the data process to the electronicdocument; and integrating the electronic document into the externalapplication without the need to modify the external application.
 22. Themethod according to claim 21, further comprising transmitting theelectronic document to the external application over the network usingan Application Programmer Interface (API) of the software application.23. The method according to claim 21, wherein the data process comprisesan optical character recognition (OCR) process, an intelligent characterrecognition (ICR) process, or a barcode recognition process.
 24. Themethod according to claim 21, wherein the software application comprisesa virtual copier operable to seamlessly replicate and transmit theelectronic document to a plurality of destination devices.
 26. Themethod according to claim 24, wherein the software application generatesa user interface that enables the conversion of the paper document intothe electronic document between the imaging device and the externalapplication using a single “GO” operation.
 25. The method according toclaim 21, further comprising providing feedback information relating toreceiving the selection of the data process.
 27. The method according toclaim 21, wherein the network comprises at least one of the Internet ora local area network (LAN).
 28. The method according to claim 21,wherein the software application comprises an input module operable tofacilitate receiving the electronic document from the imaging device.29. The method according to claim 28, wherein the software applicationcomprises an output module operable to transmit the electronic documentto the external application over the network, wherein the method furthercomprises receiving a selection of the external application as thedestination by receiving a selection of the output module.
 30. Themethod according to claim 29, wherein at least one of the input module,the output module, or the process module comprises an API forinterfacing with the external application.